一、环境：

服务器：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

服务端的分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客户端后，内存会瞬间降到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版本居然仍然存在。