架构师压测扫雷日记：性能测试的问题定位与排查（一）

背景知识

飞机直达

压测背景

某天，某项目上线前夕，所有功能性测试已经验证完成，只剩下最后的测试部门的性能测试。只要性能测试报告显示，程序功能模块性能OK，项目就可以正常上线。
而且前期的单元模块的性能测试报告显示，功能模块的性能可以达到800QPS左右。大家对本次全链路性能压测充满信心，觉得肯定可以在3天之内结束战斗。

测试方案

测试的总体方案与架构示意图如下：

这里只是画出了全链路中的部分链路，也是本次压测中需要重点关照的链路。正常情况下：

1. 云服务A会接收到上游系统推送到云消息队列RocketMQ中的消息。
2. 完成本地处理后，会提交订单到本地系统的Nginx负载。
3. Nginx负载再将支付请求转发到本地系统的连接网关，网关集群将请求调用到对应的本地系统支付服务。
4. 支付服务收到请求后，将请求数据落库户，异步推送到本地系统的中间件消息集群后，返回支付提交成功。

第一轮压测结果

Rocket MQ导入速度很快，但不能作为性能参考依据。MQ消费速度，从200-600不等。统计本地数据库记录新增，为300TPS上下，RT整体在300-400ms。
异步导入MQ速度很快，压力机性能瓶颈基本排除。
云服务A四个节点的性能监控指示，几乎没有压力，CPU,内存，磁盘IO，均为空闲状态（10%以下）。
云数据库性能指标正常，CPU使用率低于20%，内存低于70%，磁盘IO低于10%。
本地环境：nginx集群，网关集群以及支付服务均为空闲状态，整体CPU，内存，磁盘IO均空闲（20%以下）。

备注：本地系统新增服务节点，性能不升反降。

第一轮问题排查

这个压测结果，让开发组的同学们大跌眼镜，本来胜券在握的性能测试，反倒成了他们本次项目上线的一个拦路虎。于是，他们在服务A与本地系统服务都添加了耗时的打印日志。
发现本地连通网关的处理耗时，在20ms，而云服务A的整体耗时，则在300ms以上。

这时，开发负责人，为了加快项目问题的解决进度，把架构师请到到现场去加速问题排查。
当时开发同学的第一个反应是，问题出在测试专线的带宽上，因为云平台到本地系统的流量上升，导致带宽被打满，带宽打满以后，网络延时增加，导致云平台与本地系统的处理速度不对等。
架构师询问了开发负责人，单包的数据上行与下行，给到的答复是，一包数据的上下行总和大概是700字节左右。
那么我们粗略一估算，按照300的吞吐量，加上http协议的开销，在payload=700字节的情形下，网络带宽的预估应该是(700B + 300B) * 300 = 300000Bps = 300KBps = 2.4Mbps，远远没有到达专线带宽上线。
为了证实这个猜想，架构师请运维同学监控了专线带宽的使用情况，运维反馈，专线带宽在压测时的峰值使用率为2.9Mbps，基本符合估算数据。

至此，排除了带宽问题导致的性能瓶颈。那么