直播性能分析过程 - 7D-RESAR第三期后记

有人7DGroup-RESAR性能工程在线活动第三期已结束。

虽然过程有波折，在昨天的在线分享中，由于原定讲师家的网络出现问题，会议室登录不了。

所以临时改为在线答疑和在线实时分析。

结果反而得到参与者的认可，我还是比较意外的。因为好评度超过了我的预期。哈哈。

这里要多谢胡同学提供的分析案例。

在开场的过程中，胡同学临时提出可以在线分析他们的系统。这对于其他参与的人包括我来说，都是未知的系统。我觉得这样的现场分析真实案例，是非常真实的性能分析的工作场面，所以就答应了。

想不到参与的人，反应还非常好。

现记录如下，以供参考。

• 现象说明：

响应时间变长，tps不增加，资源利用率不高。

• 架构图：

这是个当前非常典型的系统架构了。spring boot的网关及微服务、nacos注册配置中心、mysql数据库。

• 压力场景数据说明

在压力的一开始，jmeter数据如下：

压力持续了一段时间之后，jmeter数据如下：

对应的TPS图如下：

从平均响应时间上来看，就可以知道，典型的响应时间增加。像扣积分、加积分，已经从50毫秒左右加到了260毫秒，并且这个是平均值，所以实际增加的比这个还要长。通过后面的90%、95%、99%线看到的增加更为明显。

从TPS图上来看，只有前两个递增的阶段，还有一点点增加的趋势，后面就完全没有了。同时，从这个图上来看，有两个问题。

1. TPS会掉下来；
2. TPS不增加；

对于分析来说，一定要先搞清楚的就是要分析什么问题。那我们这里分析什么问题呢？

其实TPS会掉下来，这个是容易分析的。根据我的分析逻辑，画性能分析决策树，再做全局监控相关性分析，是非常容易找到问题点的。

而TPS不增加，才是更复杂的性能问题。因为对于性能来说，我们一直说，不管什么系统都会有容量的上限，而对这个系统来说，TPS后面如此不稳定，所以，我们要先分析清楚瓶颈点在哪，把TPS提上去，然后再来分析TPS会掉的问题。

仗着艺高人胆大（俗称：傻小子睡凉炕，全凭火气壮），我们来现场分析TPS不增加的问题。

既然看到了响应时间增加，接下来应该做的事情是拆分响应时间，看耗时在哪一段。

但是在沟通了之后，发现他们并没有什么监控时间的手段。日志没有配置请求和响应时间记录；apm工具也没有。

因为是实时在线分析，上百人等着看，如果这时去抓包分析的话，太耗时了。还好这个系统的架构并不大，所以，我们直接来看全局监控数据。