Comet连接数测试java

本文通过测试不同并发连接数下的HTTP服务器性能,发现内存成为限制Comet应用扩展的主要因素。当连接数达到20万时,QPS已达瓶颈,继续增加连接数并无实际效益。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

操作系统:

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 服务器的性能瓶颈,链接数量再增加下去没有任何意义。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值