? 下面的配置项可能因不同的容器有不一样，但是基本原理是差不多的
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。