性能监控/优化系列——WEB容器/应用性能调优

  下面的配置项可能因不同的容器有不一样，但是基本原理是差不多的

1. Thread Pool，调优WEB容器线程池比较好的实践是首先根据基本原则设置初始化配置（下图），然后在压力环境下观察并做适当修改。

2. 对于那些重IO(examples: invocation of remote EJBs, database interactions, communicating with slow clients, file system interactions)的应用，需要观察线程池和CPU utilization，防止因为线程IO等待造成容器请求排队而CPU却闲置的情况。

3. 对于线程池utilization的监控可以通过current threadsbusy-count来完成，下面是一些常见的配置指导。

4.常用的一些监控工具JavaMelody/probe（for TOMCAT）/Hyperic HQ。

5. request-processing.threadcount的设定一般为：对于非CMT（Chip Multithreading）的CPU其值为核数的两倍；对于CMT的CPU为虚拟处理器数（指硬件线程or芯片线程）的两倍。

6. acceptor-thread用于定义selector线程数，在多处理器环境可以设置为processor数。

7.max-connections-count属性用于指定最大连接队列的大小，一旦这个队列满，那么服务器将决绝其他的连接请求。

8. buffer-size-bytes属性用于指定发生和接受byte的buffer大小，一般不需要重新配置，除非遇到大的输入和输出负载，这个值的修改一般要伴随OS级别TCP buffer的修改。

9. persistent connection的概念：单个client-servler连接支持多个请求，持久连接状态下服务器保持连接的keep-alive state。一般为了防止恶意攻击，容器都会在下列情况关闭一个持久连接。

     1）这个连接上的第一个请求和最后一个请求的时间间隔超过timeout-in-seconds值，默认为30s。

  2）通过这个连接发生的请求数超过max-requests。

10. 如果要进一步做细监控，可以在应用上包含性能统计，然后通过JMX的形式暴露出去。在自己写监控统计时常用count-based 或 timebased的方式。Apache提供了一个好用的统计包，可以在统计中使用，请参考：http://commons.apache.org/math/userguide/stat.html#a1.2_Descriptive_statistics。假如自己在应用用实现了监控MBean，还需要注册到MBeanServer中，可以将这部分逻辑放到一个servlet context listener，让它伴随servlet initialization and destruction life cycle。

11. JDK自带的gzip compressor，在高并发场景下会由于内存分配过程中的锁竞争导致性能问题，开源产品LZF compressor在高压力下有较好的表现，但是gzip compressor的压缩率要高些。

12. 在分布式缓存系统的设计上需要考虑序列化和压缩技术，下面是容器与分布式缓存的交互图：

13. 对常用静态文件进行精简，例如JS，CSS。

14. 配置web服务器使得静态文件支持缓存和压缩（一般浏览器支持gzip）。

15. 关于session持久化的优化建议：1. 尽量保持放入session的对象简单；2. 尽量保持放入session的对象的size不要太大；3. 适当的使用transient关键字；4. 像分布式缓存设计思想一样，采用好的序列化/压缩技术。

16. 分布式日志收集方案：facebook开源产品Scribe（https://github.com/facebook/scribe)），再结合一个基于Java的scribeclient——collector（https://github.com/pierre/collector），将收集的日志如入HDFS。