一、环境:
服务器:linux 4核 16G 虚拟机 1台
客户端:linux 4核 16G 2000台(模拟)
数据包大小:1036字节
二、参数设置:
ulimit -n 65536
服务端处理线程2,端口4440
客户端数据包大小:约1k
三、应答模式测试
3.1 测试
模拟2000客户端并发访问,每个客户端与服务端交互10次总共花费的时间,单位是毫秒
3.2 结果
平均:24149.5ms
每条线程平均耗时:12.07475ms
单个任务平均:1.207475ms
客户端数量[个] |
单个客户端的QPS[每秒钟应答客户端能力] |
10 |
2458次 |
50 |
1578次 |
100 |
1133次 |
1000 |
160次 |
服务端的分4次统计内存与CPU使用情况
第一次:物理内存:220m,CPU:90%~120%
第二次:物理内存:282m,CPU:90%~120%
第三次:物理内存:284m,CPU:90%~120%
第四次:物理内存:273m,CPU:90%~120%
四、推送模式测试
4.1 测试
服务端由2条线程处理2000订阅
针对服务端的每一个订阅启动10个客户端,一共是20000个客户端
模拟出20000个订阅的场景
4.2 结果
客户端数量[个] |
单个客户端的平均推送延迟 |
2W |
14ms |
1W |
5ms |
|
物理内存 |
CPU |
2W客户端推送中 |
5.2G |
210%~250% |
断掉全部客户端 |
3.4G |
198%~210% |
注:在重新打开2W客户端后,内存会瞬间降到2.6G左右,然后稳步提高,大约5分钟左右服务端稳定在5.2G左右,根据PUB/SUB原理来分析,这个时候应该是输出队列占用的物理内存,另外新版本的PUB/SUB模式,在SUB处理慢的情况下,会阻塞在SUB端,这样对PUB不造成影响。
五、问题
1)【已解决】2000个线程时,socket创建异常:通过zmq_ctx_set增加ctx的socket上线
2)【已解决】并发效率不稳定:通过zmq_setsockopt,结合服务器的内存和CPU,适当调整ZMQ_BACKLOG、ZMQ_SNDHWM ZMQ_RCVHWM参数,本次测试均为1000
3)【已解决】随着并发数提高,频繁请求服务器造成的客户端不稳定:并发访问在2W个连接,由于单机端口数量限制造成连续请求的socket不足,会造成模拟客户端为了等待系统分配socket端口造成的假死现象,通过netstat查证与服务器无关
4)【临时替代方案解决】使用zmq_recvmsg的API时会产生严重的内存泄露,目前采用zmq_recv代替方案。注:这两个API一个是针对zmq_msg结构体的传输,一个是针对buffer的传输,原本以为用zmq_msg会好一些,结果压测时造成大量内存的泄露,这个api内存泄露问题据说在3.1.X中修复过,目前我用的3.2.4版本居然仍然存在。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】博客园携手 AI 驱动开发工具商 Chat2DB 推出联合终身会员
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· ASP.NET Core - 日志记录系统(二)
· .NET 依赖注入中的 Captive Dependency
· .NET Core 对象分配(Alloc)底层原理浅谈
· 聊一聊 C#异步 任务延续的三种底层玩法
· 敏捷开发:如何高效开每日站会
· 互联网不景气了那就玩玩嵌入式吧,用纯.NET开发并制作一个智能桌面机器人(一):从.NET IoT入
· .NET 开发的分流抢票软件,不做广告、不收集隐私
· ASP.NET Core - 日志记录系统(二)
· 一个超经典 WinForm,WPF 卡死问题的终极反思
· 实现windows下简单的自动化窗口管理