Comet连接数测试java

 

操作系统：

Linux 2.6.18-164.el5xen #1 SMP Tue Aug 18 15:59:52 EDT 2009 x86_64 GNU/Linux

CPU ： 4 核

model name      : Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz

cpu MHz         : 2400.084

cache size      : 12288 KB

修改了系统参数： /etc/security/limits.conf

                                     root    soft    nofile  900000

root    hard    nofile  900000

内存：

7.5G

JVM 参数：

-server -Xms5632m -Xmx5632m -Xmn1024m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=30 -XX:SurvivorRatio=8 -verbose:gc -Xloggc:/home/rentong/logs/gc.log -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true

 

链接数	Load	CPU	系统内使用	Full GC 时间	Old 区占用
5 万	0.05	0.5%-1%	3G	无	5.69%
10 万	0.1	1%-2.2%	3.4G	无	14.02%
20 万	0.3	2%-4%	4.5G	无	27.70%
30 万	0.4	2%-4%	5.5G	无	43.32%
39 万	0.5	2%-4%	6.5G	无	65.27%

 

 

在 YGC 的时， CPU 会到 20%

当压测到 40 万时，系统内存还是占用 6.5G 。客户端接程序建立链接出现超时。服务端系统因 FUllGC 出现暂停假死情况。

 

 

服务端用 Netty 框实现 Http 服务。

客户端用 python epoll 阻塞 IO 建立大量的 Http 转义链接。

结论：在 Comet 链接数量上，内存是最重要的。 Comet 链接不可能一直等到有消息再 Reponse ，重新 Reqeust ，一般网络情况在 2 分钟没有数据传输时，交换机，路由器一些设置会断开这个链接。

当链接数到 20 万以上，以 60S 重新 Request 一次计算， 3.3 万的 QPS 已经成 HTTP 服务器的性能瓶颈，链接数量再增加下去没有任何意义。