当前位置: 首页 > 分布式系统 > 正文

PipeComet长连接测试

关键字:
1 星2 星3 星4 星5 星 (2 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

PipeComet这个支持长连接,异步请求事件处理框架做了测试也快有5天了,这里做一个简单的总结,但这个文档中的数字不能作为最终容量的定论,后续还会在优化后有进一步的测试。同时这个文档更倾向于分享过程中的遇到的一些问题,可以避免走一样的弯路。

测试环境:
1台部署了Jetty Web容器作为PipeComet服务端。

2台windows测试机部署了两个LoadRunner,作为压力测试客户端。(一个用于建立大量长连接,一个用于产生http请求模拟外部事件激发数据片段下发)

服务端配置如下:
Xen虚拟机,5核(2.40 GHz),8G内存。
Jetty 7.1.6版本,jdk 1.6.0_25

JVM配置:-Xms7g -Xmx7g -XX:PermSize=96m -XX:MaxPermSize=256m -Xmn3g

Jetty配置:

<Set name=”ThreadPool”>
<!Default queued blocking threadpool –>
<New class=”org.eclipse.jetty.util.thread.QueuedThreadPool>
<Set name=”minThreads”>400</Set>//最小和最大线程池设置的都有一点大,后面大致说一下
<Set name=”maxThreads”>800</Set>
</New>
</Set>
<Call name=”addConnector”>
<Arg>
<New class=”org.eclipse.jetty.server.nio.SelectChannelConnector>
<Set name=”host”><Property name=”jetty.host/></Set>
<Set name=”port”><Property name=”jetty.portdefault=8080/></Set>
<Set name=”maxIdleTime”>3600000</Set> //无数据传输的连接保持多久,单位毫秒
<Set name=”Acceptors”>4</Set>
<Set name=”statsOn”>false</Set>
……
</New>
</Arg>
</Call>

测试场景描述:
1.启动服务端,并建立有Condition模式的管道配置。

2.压力测试机A通过LoadRunner并发启动N个vuser,与服务端建立N个长连接会话,服务端建立N个事件挂起当前多个请求,等待外部消息激发下行数据片段或者关闭会话。

3.压力测试机B通过LoadRunner并发启动P个vuser,随机的发起激发某一个长连接会话下行数据片段的请求,服务端接收请求后,主动向下推送数据片段。

这里有两个参数N和P,N就代表单机支持多少长连接,P代表并发创建多少个事件去激发下行数据。

事先环境准备:
Linux:(这块做过高并发测试的一般都还是会比较注意)
调整一下/etc/sysctl.conf的一些系统参数:(具体不解释了,看上面的英文注释)

#add by fangweng
fs.file-max = 65535
#Allow for more PIDs
kernel.pid_max = 65536
#Increase system IP port limits
net.ipv4.ip_local_port_range = 2000 65000
# TCP and memory optimization
# increase TCP max buffer size setable using setsockopt()
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
# increase Linux auto tuning TCP buffer limits
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000

修改后:

sysctl -p /etc/sysctl.conf        // 作用:重新载入/etc/sysctl.conf文件

Window调整(这个一定要注意)
放火墙和杀毒软件关掉!!!
注册表中修改

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters

修改里面:

TcpTimedWaitDelay 为1(原来30)
MaxUserPort 65534
LoadRunner参数调整:
LoadRunner在为长连测试的时候,需要修改Run-time Settings,红色部分尽量大一些

测试:
1. 并发2000个连接保持会话。

2. 并发100个VUser模拟向100个长连接发起事件驱动消息。

观察得到的结果:
1. 建立起2000个连接过程中load保持在0.1到0.3左右,完全建立好后也就0.1多。(表明建立连接后现在的事件驱动处理方式没有空转损耗)

2. 并发100个Vuser开始循环压测的时候,会有少数几个连接主动掉线。(为了看是服务端主动断连还是客户端发起,执行了tcpdump,从抓包的结果可以看到客户端主动的发起了Fin消息,当前只能认为在大量数据包下行的情况下,系统还是有保护的将下发数据频率过高的连接断开了,当防火墙或者杀毒软件打开的时候,更是容易屏蔽,这点为将来长连在客户端的问题处理也积累经验)

3. 并发100个Vuser测试时,Load有明显上升,在1-2.6之间,同时通过vmstat可以看到上下文切换数量递增了两个数量级。Sar方式统计也可以很明显的看到在数据大量输入输出时,整个框架的系统消耗不小。

于是,开始判断哪里出了问题。
Load变高作为java程序员如何判断哪里出了问题呢,以下是我的经验排查方式:

1. GC是否比较频繁。(直接看gc log或者jstat gcutil)
2. IO消耗是否比较大。(cpu占用率到不高,vmstat)
3. 是否有代码空转。(cpu占用率很高,往往就几个线程长期持有cpu)
4. 是否有大量的线程Blocked。(dump线程出来看看)

在刚才的测试基础上做了一个简单的对比,如果把一百个并发请求分散到500个事件随机触发上,整理的load要低于100个事件随机模拟,也就是说数据越集中到某几个连接的事件上,消耗越大。

本地jprofiler测试了一下,看到大量的blocked线程是在处理消息输出的时候。原来当时为了简单处理并发,在response上面就增加了一个写锁,保证每次输出时候能够支持并发,但write这个动作被放在锁里是否适合?其实就是把一个时间消耗较长的动作去做了同步,最终其实使得在并发比较高,压力比较大时,竞争和阻塞厉害,导致系统消耗增大。因此还是按照传统的tcp sendbuffer模式,挂接内容支持多线程并发,输出数据为单线程循环发送,再简单测试了一下,Load明显下去了,基本就在1左右。

你可以尝试着去看vmstat,里面的procs中的r其实表示统计瞬时需要执行的任务队列长度,你会发现有时候通过top看到的load很低,但是r还是会有些上下波动,但如果任务执行的快,其实对于load影响不大。
继续测试:

并发连接数	事件激发模拟用户数	Load(建立连接过程)	Load(事件处理过程)
2000	10050个事件随机选取)	0.1 - 0.3	0.61.2
5000	10050个事件随机选取)	0.10.3	0.71.4
5000	200100个事件随机选取)	0.10.3	0.81.6

这个数据并不能反映容量,但是可以说明的是,长连接数量对于系统在高并发事件处理影响不是很大,建立长连接和管理长连接所属的事件并不消耗系统资源(cpu,内存都观察过)

本文固定链接: http://www.chepoo.com/pipecomet-test.html | IT技术精华网

PipeComet长连接测试:等您坐沙发呢!

发表评论