tomcat 最大并发数

只针对BIO模式,目标请求会sleep两秒再返回结果,通过jmeter测试工具进行并发测试

操作系统:windows && linux

tomcat7测试:

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000" maxThreads="1" acceptCount="2" 
redirectPort="8443" />

文档:http://localhost:8080/docs/config/http.html

官方解释:acceptCount对暂时无法执行的请求进行队列保存,超出设置则拒绝连接。

测试发现无法限制住最大并发数,所有请求都可以依次执行,每次有1个线程执行(maxThreads=1)

最大并发数如果过大,大于acceptCount值好几倍,会随机出现连接被拒绝。

进一步调查-----------------------------------------------------------------------------------------------------------------------------------

首先关于tcp queue简单介绍:

tcp三次握手:

第一次,客户端发送syn,等待服务端确认,此时客户端进入SYN_SEND状态

第二次,服务端接收syn包并确认,发送syn+ack给客户端,此时服务端进入SYN_RECV状态

第三次,客户端收到syn+ack,再次向服务端发送ack,此时客户端进入ESTAB状态(注意,此时服务端未必进入ESTAB状态

 

半连接队列:服务端维护的与客户端保持SYN_RECV状态的连接队列,等待客户端回复,当收到客户端ack后,如果条件允许(全连接队列未达到最大值),服务端进入ESTAB状态,从半连接队列移到全连接队列的队尾。

全连接队列:完成三次握手等待accept。完成三次握手即进入了全连接队列的队尾,当进程调用accept时,全连接队列中的队头项将返回给进程,并从队列中移出连接。如果该队列为空,那么进程将被投入睡眠,直到TCP在该队列中放入一项才唤醒它。

在listen(int sockfd, int backlog)中,backlog在Linux 2.2之后表示的是已完成三次握手但还未被应用程序accept的队列长度。

 

全连接队列满,半连接队列未满:

客户端发出syn分节,服务端收下,并向客户端发出syn+ack。

客户端收到服务端syn+ack后,成为ESTAB状态,向服务端发送第三次握手ack。

服务端收到ack后,发现全连接队列已满,默认情况下,服务端什么也不做,状态依然是SYN_RECV。

客户端会重传syn和ack,当达到一定的阈值(/proc/sys/net/ipv4/tcp_synack_retries)时,客户端与服务端断开连接,服务端删除客户端在半连接队列中的syn分节。

全连接、半连接队列都满:

客户端发出syn分节,服务端发现半连接队列已满,直接丢弃syn,使客户端重传syn。

客户端重传syn,再次到达服务端后,服务端发现已经重传过,则收下,并告诉客户端syn+ack。

后续流程与上述一致,相比之下,多了一次客户端重传syn分节。

修改tcp参数配置:

tcp_synack_retries和tcp_syn_retries定义SYN 的重试连接次数

/etc/rc.d/rc.local文件中追加:

sysctl -w net.ipv4.tcp_synack_retries=3

sysctl -w net.ipv4.tcp_syn_retries=3

重启。

也可直接执行命令:

sysctl -w net.ipv4.tcp_synack_retries=1

sysctl -w net.ipv4.tcp_syn_retries=3

关于队列的长度:

半连接队列:≈2 * min(backlog, net.ipv4.tcpmax_syn_backlog) 

全连接队列:min(/proc/sys/net/core/somaxconn(本系统128), backlog),表示最多有 min() + 1个 ESTAB 的连接等待 accept()。

修改somaxconn,

在/etc/sysctl.conf中添加如下:

net.core.somaxconn = 2048

然后在终端中执行

sysctl -p

进一步试验-------------------------------------------------------------------------------------------------------------------------------------------------------------------

在linux下,通过ss -ant进行观察tcp queue

并发5个请求

 

acceptCount配置作为socket中的backlog的值,如果acceptCount不设置或者设置为0,则会取默认值,经测试是100。

全连接队列大小为 min(/proc/sys/net/core/somaxconn(本系统128), 2) + 1=3,即等待服务端accept的ESTAB状态的连接最多有3个,如Recv-Q所示。

3个Recv-Q为323(表示请求bytes数值)的ESTAB状态的连接正等待server accept

1个Recv-Q为0的ESTAB状态的连接表示server端已经accept了请求,只是还没有返回结果(sleep中)。

1个SYN-RECV状态是半连接状态,位于半连接队列当中(此时客户端已经处于ESTAB状态),全连接队列已经满了。

对于处在半连接状态的连接,客户端会定时重发,直至达到阈值,如下:

第一次握手

 第二次握手

 第三次握手

 客户端发送数据包

但由于此时服务端未能将连接从半连接队列移至全连接队列,状态依然是SYN-RECV,即未得到服务端ack,因此客户端继续发数据包

发送几次之后,服务端有了回应,告诉客户端说,你之前发的包丢了

然后客户端也告诉服务端,丢失的状态、对应的id号及次数,这里的43就是第三次握手的43,失败次数是1

然后客户端又开始重传了

终于服务端受不了了,此时客户端服务端彻底断开。

通过调整ipv4.tcp_synack_retries和ipv4.tcp_syn_retries,可以增加重试次数

 

结论:

对于tomcat中的acceptCount只是全连接队列的大小,就是说客户端和服务端都已经是ESTAB状态的连接,不考虑connectionTime的情况,在此队列中的连接最终都会被处理。对于大于acceptCount的连接请求,如果在tcp重试阈值范围之内完成半连接到全连接的状态转换,那么还是有机会被服务端accept并处理的。

因此,不能说只要大于acceptCount的连接就一定被拒绝!

 

 

参考文献:

http://www.cnblogs.com/leezhxing/p/5329786.html

http://blog.chinaunix.net/uid-24782829-id-3456109.html

http://www.cnblogs.com/menghuanbiao/p/5212131.html

http://www.cnblogs.com/zengkefu/p/5606696.html 有详细的源码分析

posted @ 2016-09-30 15:36  小N~  阅读(9199)  评论(0编辑  收藏  举报