我正在写一个服务器，当收到请求时，我将每个动作发送到一个单独的线程。我这样做是因为几乎每个请求都要进行数据库查询。我正在使用线程池库来减少线程的构造/破坏。
我的问题是:对于这样的I/O线程，什么是一个好的截断点?我知道这只是一个粗略的估计，但我们说的是几百吗?成千上万的吗?
我怎么才能算出这个界限呢?
编辑:
感谢大家的回复，似乎我只是要测试一下，以找出我的线程数上限。问题是:我怎么知道我已经达到上限了呢?我到底应该测量什么?
当前回答
我认为这有点回避你的问题，但是为什么不把它们分成进程呢?我对网络的理解(从以前模糊的日子里，我根本就没有编写网络代码)是每个传入的连接都可以作为一个单独的进程来处理，因为如果有人在您的进程中做了一些讨厌的事情，它不会破坏整个程序。
其他回答
需要考虑的一件事是，将执行代码的机器上有多少内核。这表示在任何给定时间内可以处理多少线程的硬限制。但是，如果像您的情况一样，线程需要频繁地等待数据库执行查询，那么您可能需要根据数据库可以处理多少并发查询来调优线程。
正如帕克斯所说，衡量，而不是猜测。这就是我为DNSwitness所做的事情，结果令人惊讶:理想的线程数比我想象的要高得多，大约15,000个线程才能获得最快的结果。
当然，这取决于很多东西，这就是为什么你必须衡量自己。
在Combien de fils d'exécution ?中的完整测量(仅法语)。
你应该记住的一件事是，python(至少是基于C的版本)使用了所谓的全局解释器锁，它可以对多核机器的性能产生巨大影响。
如果你真的很需要多线程python，你可能会考虑使用Jython或其他东西。
“大铁”的答案通常是每个有限的资源一个线程——处理器(CPU限制)，臂(I/O限制)等等——但这只有在您能够将工作路由到要访问的资源的正确线程时才有效。
在不可能的情况下，考虑您拥有可替代资源(cpu)和不可替代资源(武器)。对于CPU来说，将每个线程分配给特定的CPU并不重要(尽管这有助于缓存管理)，但对于手臂，如果不能将线程分配给手臂，则需要考虑排队理论以及让手臂忙碌的最佳数量。一般来说，我认为如果您不能基于所使用的臂路由请求，那么每个臂有2-3个线程将是正确的。
当传递给线程的工作单元没有执行合理的原子工作单元时，就会出现复杂情况。例如，你可以让线程在一个点访问磁盘，在另一个点在网络上等待。这增加了“裂缝”的数量，其他线程可以进入并做有用的工作，但它也增加了其他线程污染彼此缓存的机会，等等，并使系统陷入困境。
当然，您必须将所有这些与线程的“重量”进行权衡。不幸的是，大多数系统都有非常重量级的线程(而他们所谓的“轻量级线程”通常根本就不是线程)，所以最好在低级别上犯错。
我在实践中看到的是，非常细微的差异可能会对最佳线程的数量产生巨大的影响。特别是，缓存问题和锁冲突会极大地限制实际并发的数量。
如果您的线程正在执行任何类型的资源密集型工作(CPU/磁盘)，那么您很少会看到超过一到两个的好处，太多会很快降低性能。
“最好的情况”是，当第一个线程完成时，后面的线程将会停止，或者一些线程在资源上有低开销的块，且资源争用低。最坏的情况是您开始折腾缓存/磁盘/网络，并且您的总体吞吐量下降到地板。
一个好的解决方案是将请求放在一个池中，然后从线程池分派给工作线程(是的，避免持续的线程创建/销毁是很好的第一步)。
然后，可以根据概要分析的结果、正在运行的硬件以及机器上可能发生的其他情况调整和缩放此池中的活动线程数。
