如果你不了解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