PipeComet测试

最新推荐文章于 2024-11-04 16:54:34 发布

wxy_fighting

最新推荐文章于 2024-11-04 16:54:34 发布

阅读量639

点赞数

分类专栏： java 文章标签：并发处理器测试 Java

java 专栏收录该内容

234 篇文章 0 订阅

订阅专栏

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="minThreads">400</Set>//最小和最大线程池设置的都有一点大，后面大致说一下

</New>

</Set>

<Arg>

<Set name="maxIdleTime">3600000</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	100（50个事件随机选取）	0.1 - 0.3	0.6 – 1.2
5000	100（50个事件随机选取）	0.1 – 0.3	0.7 – 1.4
5000	200（100个事件随机选取）	0.1 – 0.3	0.8 – 1.6