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 有详细的源码分析