有些人会说两个线程太多 - 我不是那个阵营:-)
这是我的建议:衡量,不要猜测 . 一个建议是使其可配置并最初将其设置为100,然后将软件发布到野外并监控发生的情况 .
如果你的线程使用率达到3,那么100就太多了 . 如果它在一天中的大部分时间保持在100,那么将其提高到200,看看会发生什么 .
您实际上可以让您的代码本身监视使用情况并在下次启动时调整配置,但这可能是过度的 .
澄清和阐述:
我不是主张滚动你自己的线程池子系统,一定要使用你拥有的那个 . 但是,既然你问的是线程的一个很好的截止点,我假设你的线程池实现能够限制创建的最大线程数(这是一件好事) .
我编写了线程和数据库连接池代码,它们具有以下功能(我认为这对性能至关重要):
最小活动线程数 .
最大线程数 .
关闭一段时间未使用的线程 .
第一个根据线程池客户端设置最低性能的基线(此线程数始终可用) . 第二个设置了活动线程对资源使用的限制 . 第三个会在安静时间返回基线,以最大限度地减少资源使用 .
您需要 balancer 具有未使用线程(A)的资源使用与没有足够线程来执行工作的资源使用(B) .
(A)通常是内存使用(堆栈等),因为不执行任何工作的线程将不会使用大量的CPU . (B)通常会在请求处理时延迟处理请求,因为您需要等待线程可用 .
这就是你测量的原因 . 正如您所述,绝大多数线程将等待数据库的响应,因此它们将不会运行 . 有两个因素会影响您应该允许的线程数 .
第一个是可用的DB连接数 . 这可能是一个硬限制,除非您可以在DBMS上增加它 - 我将假设您的DBMS在这种情况下可以采用无限数量的连接(尽管您理想情况下也应该测量它) .
然后,您应该拥有的线程数取决于您的历史用途 . 你应该运行的最小值是你运行A%的最小数量,绝对最小值(例如,并使其像A一样可配置)5 .
最大线程数应为历史最大B% .
您还应该监视行为更改 . 如果由于某种原因,您的使用时间达到可用时间的100%(这会影响客户的性能),您应该提高允许的最大值,直到它再次高出B% .
回答"what exactly should I measure?"问题:
您应该具体衡量的是在负载下并发使用的最大线程数(例如,等待从DB调用返回) . 然后添加一个10%的安全系数(强调,因为其他海报似乎把我的例子作为固定的建议) .
此外,这应该在 生产环境 环境中进行调整 . 可以事先得到一个估计,但你永远不知道什么样的产品会引发你的方式(这就是为什么所有这些东西都应该在运行时配置) . 这是为了捕捉到一些情况,例如客户来电的意外加倍 .