使用技巧：Java EE性能问题解决手册6

　　图8显示了服务器的处理程序。

　　Figure 8. 服务器处理请求的次序结构

　　线程池太小

　　每当我碰到有人抱怨装载速度的性能随着装载的数量的增加变的越来越糟糕的时候，我会首先检查线程池。特别是，我在看到下面这些信息的时候:

• 　　1.线程池的使用
• 　　2.很多请求等待处理(在队列中等待处理)

　　当一个线程池被待处理的请求装满的时候，响应的时间就变的极其糟糕，因为这些在队列中等待处理的请求会消耗很多的额外时间。这个时候，CPU的利用率会非常低，因为程序服务器没有时间去指挥CPU工作。这个时候，我会按一定幅度增加调节池的大小，并在未处理请求的数量减少前一直监视程序的吞吐量，你需要一个合理甚至更好的负载量者，一个精确的负载量测试工具可以准确的帮你测试出结果。当你观测吞吐量的时候，如果你发现吞吐量降低了，你就应该把池的大小下调一个幅度，一直到找到让它保持最大吞吐量的大小为止。

图9显示了连接池太小的情况

　　Figure 9. 所有的线程都被占用了，请求就只能在队列中等待

　　每当我阅读性能调整手册的时候，最让我头疼的就是他们从来不告诉你特殊情况下线程池应该是多大。由于这些值非常依赖程序的行为，他们只告诉你大普通情况下正确的大小，但是他们给了你一个范围内的值，这对用户很有利的。例如考虑下面2种情况::

• 　　1. 一个程序从内存中读出一个字符串，把它传给JSP页面，让JSP页面去显示
• 　　2. 另一个程序从数据库中读出1000个数值，为这些不规则的数值求平均。第一个程序对请求的回应会很块，大概仅需要不足0.25秒的时间，且不怎么占据CPU。第二个程序可能需要3秒去回应，同时会占据CPU。因此，为第一个程序配置的池大小是100就有点太小了，因为程序能够同时处理200个;但为第二个程序配置的池是100，就有点太大了，因为CPU可能就能应付50个线程。

　　但是，很多程序并没有在这种情况下动态的去调整的功能。多数情况下是做相同的事，但是应该为他们划分范围。因此，我建议你为一个CPU分配50到75个左右的线程。对一些程序来说，这个数量可能太少，对另一个些来说可能太多，我刚开始为每个CPU分配50到75个线程，然后根据吞吐量和CPU的性能，并做适当的调整。