如果你不了解PipeComet，请先看看：
http://blog.csdn.net/cenwenchu79/archive/2011/05/27/6450427.aspx
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.port" default="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 |
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 |
这个数据并不能反映容量，但是可以说明的是，长连接数量对于系统在高并发事件处理影响不是很大，建立长连接和管理长连接所属的事件并不消耗系统资源（cpu，内存都观察过）
这篇分享中没有介绍测试中对于并发处理在异步事件驱动中的修改，具体的后续可以比较一下上次公布出来的代码和新代码的区别，简单来说：
1． 原本可以状态不脱离于线程，使得状态不比担心多线程并发控制，现在需要关注状态和资源的并发控制（例如request的lazy解析，response的输出，ThreadLocal的数据传递和复制）。
2． 客户端可以主动断开服务端，服务端网络失败也可以断开客户端，因此在任何一个对于悬挂起的异步web请求处理时都需要做好检查和资源回收处理，防止资源泄露。
3． 系统的事件驱动模型状态变更及对象内容变化要提供接口来保证用户操作时可以支持多线程并发处理。
待续…