广播系统测试总结

系统介绍

作为基础服务，这套系统目前是公司性能要求最高的服务啦，这套系统分三个服务分别以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