acceptCount值调整(默认100)
acceptCount的经验值的范围为50-300，当tomcat的处理能力不够快的时候，可以调整该值，比较有用。
当系统的并发量比较大的时候，关闭keep alive，然后适当调整该值
当连接建立之后，经常得不到worker线程处理时，可以适当降低该值，开启keep alive
当该值设置为比较大的时候，请求的突增，会很快填满accept队列(完成三次握手建立连接，等待工作线程处理响应，如果一直没得到service，则client得不到响应，出现read timeout，最糟糕的情况是连接在accept队列等待了很久，等到能得到worker线程服务的时候，已经超时了，这样其实浪费了很多连接)，让woker线程非常繁忙，当超过系统的承受能力的时候，请求不断堆积，然后导致工作线程cpu饿死(starvation)。因此需要系统进行自我保护，当超出负载能力的时候，迅速fail fast，返回503。
因此要合理评估系统高峰的时候，worker线程池的大小。假设server平均每个请求耗时5ms，那么1个线程每秒rps可以有200，假设有4核cpu，那么每秒最大可以有800rps。现在假如有4个请求同时进来，那么4个线程将繁忙起来，也就是接下来的5ms中，这些线程时繁忙的。那么对于这个4核cpu的系统来说，最大的rps就是800.
当acceptCount的值设置的太小的时候，当请求量大的时候，操作系统无法给tomcat建立更多的连接(无法完成三次握手)，client端出现很多connect timeout，而这些被拒绝掉的请求可能是在worker线程的处理能力之内的。
当开启http keep alive的时候，client端可能没有那么及时地关闭连接，那么server端的worker线程会一直被这些实际上可能不活跃的连接给占用了，导致worker线程没能重复利用起来。但是关闭http keep alive的时候，频繁的地进行tcp连接和端口，这样会造成很多TIME_WAIT的socket，给服务端增加压力。
maxThreads值调整(默认200)
经验值范围为200-800，可以从400设置起再进行调优
代表最大的并发请求数
当cpu利用率高的时候，不宜增加线程的个数，可以调小该值
当cpu利用率不高，大部分是io阻塞类的操作时，可以适当增加该值
connectionTimeout(默认值为60000毫秒)
经验值为2000-60000，默认的60秒对于一个web server可能太高了，可以设置为3000
实际上指的是SO_TIMEOUT参数的值
代表在阻塞读写时，两个tcp包到来的最大间隔时间
当client比较慢的时候，可以增大该值
当需要快速超时时，可以降低该值
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。