5fc9eeb2902699630.jpg_fo742.png

connectionTimeout 超时时间

调整范围2000-60000,默认是60000ms,建议3000ms
实际上指的是SO_TIMEOUT参数的值,代表在阻塞读写时,两个tcp包到来的最大间隔时间
当client比较慢的时候,可以增大该值
当需要快速超时时,可以降低该值

maxThreads 最大并发请求数

调整范围200-800,默认是200
当cpu利用率高时,适当降低此值
当cpu利用率不高,大部分是io阻塞类的操作时,适当增加该值

acceptCount

调整范围50-300,默认100
当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,给服务端增加压力。

tomcat常用配置注释:

URIEncoding=”UTF-8″ 指定Tomcat容器的URL编码格式。
disableUploadTimeout=”true” 上传时是否使用超时机制
enableLookups=”false”–是否反查域名,默认值为true。为了提高处理能力,应设置为false
compression=”on”   打开压缩功能
compressionMinSize=”10240″ 启用压缩的输出内容大小,默认为2KB
noCompressionUserAgents=”gozilla, traviata”   对于以下的浏览器,不启用压缩
compressableMimeType=”text/html,text/xml,text/javascript,text/css,text/plain” 哪些资源类型需要压缩

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

Captcha Code