系统介绍
作为基础服务,这套系统目前是公司性能要求最高的服务啦,这套系统分三个服务分别以A,B,C代替
A:服务于gateway、B
B:服务于A、gateway
C:服务于其他服务、B
测试环境
centos7
20核,40processor
125G
万兆网卡,40队列
测试步骤
情景一:
目的是通过工具和各种服务混搭,测出单进程A的压力到底是多少
物理机a部署1个A和2个C, 物理机b部署5个B,物理机c部署12个gateway tool,线程数各开启20个(合理数目,不建议再大),size 65536, sink 1,glog info级别,这是个生产消费模型,生产1个线程,消费20个
A: recv 15w/s, send 75w/s, cpu占比35%,各线程占比80%~95%压力较大,单进程发送上限不要超过70w/s,开启spdlog基本没影响
rx tx rxkB txkB
15w 76w 1w 4.8w
B: A_recv 15w/s,不开启send spdlog情况, cpu总占比6%,单进程cpu不超过80%,开启后,总cpu占比15%,各进程cpu占比190%
rx tx rxkB txkB
75w 500 5w 70
机器b中途遇到问题,cpu不高,查看带宽,丢包参数,网卡参数,sokect缓存等都没有任何错误,最后发现是软中断过于集中一个cpu导致,性能一直上不去
情景二:
我们知道A的压力后,a机器上部署合理数目A,分担压力,然后测出单进程B的压力
物理机a部署2个A和2个C, 物理机b部署1个B,物理机C部署12个gateway tool,和8个C tool
A: recv 15w/s, send 35w/s, cpu占比20%,各线程占比50%~60%
B: C_recv 20w/s, A_recv 12w/s, send 100w/s,cpu占比7%, 各线程占比20%~50%,未开spdlog,打开spdlog除了send的选项,基本没影响,再打开send选项之后cpu迅速2000+%
rx tx rxkB txkB
32w 100w 4w 15w
B: C_recv 10w/s, A_recv 12w/s, send 70w/s,打开spdlog情况,cpu占比25%, 各线程占比80%~95%压力较大,单进程发送上限不要超过60w/s
B系统稳定后,接下来调整为,物理机a部署2个A和1个C,物理机b部署5个B,测试bcp单进程压力
C: recv 26w/s,send 33w/s, 各线程占比40%~50%,send不超过40w/s,开启spd后recv 15w/s, send 20w/s,各线程占比80%~95%压力较大,单进程发送上限不要超过20w/s
情景三:
各个进程性能已经得到,接下来测试机器压力
物理机a部署2个A和2个C, 物理机b部署5个B,物理机C部署12个gateway tool,和8个C tool
A
rx tx rxkB txkB
20w 100w 1w 6.5w
B
rx tx rxkB txkB
132w 230w 12w 36w
总结
测试过程中要开启监测工具,从应用层面查看是否丢包
C压力在发包和spdlog,单进程发送量最大不要超过20w
B压力在发包和spdlog,单进程发送量最大不要超过60w
A压力在于发包,单进程发送量最大不要超过70w
最终的目的是:
根据压力测试找出瓶颈
根据流量,计算出每个机器部署的片数,和需要的机器数
目前线上流量百万级,并且毫无压力
测试结果显示出C服务压力很大,明明只是转发而已,竟然比A,B服务压力还大,找代码,最终发现glog info级别导致频繁写Log,并且还是一个无用的Log,接下来会把Log级别修改为warning再进行测试,不开spd情况,从recv 26w/s,send 33w/s,优化后recv 52w/s,send 65w/s