一). 总结:
1. 在不影响应用延迟的情况下,短链接(3.3W)和长链接(15.5W) QPS差异在5倍。
2. 在长链接(延迟无明显增加)情况下,应用无报错,且平均延迟降低50%左右 。
3. codis proxy单节点QPS最大承载量如下:
机器型号 | QPS | 最大系统指标(cpu) |
---|---|---|
8c32G | ~15.5W | 75% |
32c128G | ~22.5W | 75% |
二). 测试明细:
1. 测试机型:
后端服务个数 | codis proxy个数 | proxy 配置 | 后端服务器配置 | 压测工具 | 压测命令 |
---|---|---|---|---|---|
20个 | 8个 | 8c 32G | 32C 128G | ab + jmeter | ab -c 10000 -n 2000000 http://interact.int.yidian-inc.com/test/ttt/redistest |
20个 | 8个 | 8c 32G | 32C 128G | ab + jmeter | jmeter -n -t redis3.jmx -l log1.jtl -Jthn=100000 -Jloopn=999999999 |
备注:redis自带压测工具
./redis-benchmark -t set,get -h 10.138.20.97 -p 19000 -n 5000000 -d 384 -k 0 -c 1000 --threads 10
2. 短链接压测:
链接请求方式:一次连接,两次操作(一读一写)
机器数量*单机并发线程数 | 请求总次数 | 压测次数 | avg 单节点proxy QPS | avg 8台总QPS | 业务错误条数均值 | 后端服务延迟 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1*10000 | 6000000 | 4 | 0.97W (0.97W 0.97W 0.98W 0.96W) | 7.6W (7.7W 7.6W 7.8W 7.7W) | 1.3 (0, 0, 4 ,1) | 16ms | ||||||||||||
2*10000 | 6000000*2 | 4 | 1.9W (1.9W 1.9W 1.8W 1.9W) | 15.3W (15.4W 15.4W 15.2W 15.2W) | 0 (0, 0, 0 ,0) | 44ms | ||||||||||||
3*10000 | 6000000*3 | 3 | 2.85W (2.85W 2.85W 2.85W ) | 22.5W (22.5W 22.5W 22.5W) | 10.3 (12, 11 ,8) | 340ms | ||||||||||||
4*10000 | 6000000*4 | 3 | 3.3W (3.3W 3.3W 3.3W ) | 26.5W (26.5W 26.5W 26.5W) | 19 (32 ,7 ,18) | 400ms | ||||||||||||
5*10000 | 6000000*5 | 2 | 3.3W (3.3W 3.3W ) | 26.5W (26.5W 26.5W ) | 16 | 420ms |
总结:当使用短链接访问codis proxy,单个proxy 达到3w qps,需要扩容proxy的个数提升整个集群的qps,当单压一个proxy的时候,proxy最大可以达到5.4万,axe服务延迟上升到1500ms。后端日志有非常多的报错。
3. 短链接调整内核后压测:
优化方式:
内核参数 tcp time_wait 重用 net.ipv4.tcp_timestamps 0 ---> 1
链接请求方式:一次连接,两次操作(一读一写)
压测机器数量*线程数 | 请求总次数 | 压测次数 | avg 单节点proxy QPS | 未优化时均值 | avg 总QPS | avg 业务错误条数 | 未优化错误均值 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1*10000 | 6000000 | 1 | 0.96W | 0.97W | 7.5w | 0 | 1.3 | ||||||||||||
2*10000 | 6000000*2 | 3 | 1.9W | 1.9W | 15.3W | 68,39, 77 | 0 | ||||||||||||
3*10000 | 6000000*3 | 1 | 2.85W | 2.85W | 22.5W | 116 | 10.3 | ||||||||||||
4*10000 | 6000000*4 | 1 | 3.4W | 3.3W | 27W | 503 | 19 |
结论: 效果未好转,应用错误数稍微增多。
4. 长链接压测:
单台压测:
链接请求方式:一次连接,两次操作(一读一写)
压测机器数量*线程数 | 请求总次数 | 压测次数 | avg 单节点proxy QPS | avg 业务错误条数 | proxy CPU使用 | 运维监控阀值 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2*10000 | 6000000 * 2 | 3 | 32C:15.5W 8C:15.5W | 0 | 32C:20% 8C:75% | 70% | ||||||||||||
3*10000 | 6000000 * 3 | 3 | 32C:22.5W 8C:20W | 0 | 32C:75% 8C:98% | 70% | ||||||||||||
4*10000 | 6000000 * 4 | 3 | 32C:30W | 0 | 32C:80% | 70% |
总结:32c 128G的proxy节点qps最大15.5W,CPU利用率20%,业务监控指标后端延迟10ms左右,业务无报错。
集群压测:
链接请求方式:一次连接,两次操作(一读一写)
压测机器数量*线程数 | 压测次数 | avg 总QPS | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
6 * 10000 | 2 | 46W | ||||||||||||
4 * 100000 | 1 | 70W |
总结:32c 128G的proxy节点qps最大15.5W,CPU利用率20%,业务监控指标后端延迟10ms左右,业务无报错。