有人7DGroup-RESAR性能工程在线活动第三期已结束。
虽然过程有波折,在昨天的在线分享中,由于原定讲师家的网络出现问题,会议室登录不了。
所以临时改为在线答疑和在线实时分析。
结果反而得到参与者的认可,我还是比较意外的。因为好评度超过了我的预期。哈哈。
这里要多谢胡同学提供的分析案例。
在开场的过程中,胡同学临时提出可以在线分析他们的系统。这对于其他参与的人包括我来说,都是未知的系统。我觉得这样的现场分析真实案例,是非常真实的性能分析的工作场面,所以就答应了。
想不到参与的人,反应还非常好。
现记录如下,以供参考。
响应时间变长,tps不增加,资源利用率不高。
这是个当前非常典型的系统架构了。spring boot的网关及微服务、nacos注册配置中心、mysql数据库。
在压力的一开始,jmeter数据如下:
压力持续了一段时间之后,jmeter数据如下:
对应的TPS图如下:
从平均响应时间上来看,就可以知道,典型的响应时间增加。像扣积分、加积分,已经从50毫秒左右加到了260毫秒,并且这个是平均值,所以实际增加的比这个还要长。通过后面的90%、95%、99%线看到的增加更为明显。
从TPS图上来看,只有前两个递增的阶段,还有一点点增加的趋势,后面就完全没有了。同时,从这个图上来看,有两个问题。
对于分析来说,一定要先搞清楚的就是要分析什么问题。那我们这里分析什么问题呢?
其实TPS会掉下来,这个是容易分析的。根据我的分析逻辑,画性能分析决策树,再做全局监控相关性分析,是非常容易找到问题点的。
而TPS不增加,才是更复杂的性能问题。因为对于性能来说,我们一直说,不管什么系统都会有容量的上限,而对这个系统来说,TPS后面如此不稳定,所以,我们要先分析清楚瓶颈点在哪,把TPS提上去,然后再来分析TPS会掉的问题。
仗着艺高人胆大(俗称:傻小子睡凉炕,全凭火气壮),我们来现场分析TPS不增加的问题。
既然看到了响应时间增加,接下来应该做的事情是拆分响应时间,看耗时在哪一段。
但是在沟通了之后,发现他们并没有什么监控时间的手段。日志没有配置请求和响应时间记录;apm工具也没有。
因为是实时在线分析,上百人等着看,如果这时去抓包分析的话,太耗时了。还好这个系统的架构并不大,所以,我们直接来看全局监控数据。