一、环境：
服务器：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版本居然仍然存在。
