性能问题分析排查的实践方法

知识星球有同学遇到了一个性能问题，问题表现是这样的：静态资源放在Nginx，资源大概十几M大小，Nginx用docker部署，压测时发现静态资源加载很慢。在群里问该如何排查和分析。

这是很常见的一种性能问题，导致这种现象的原因一般是带宽、内存等资源不足导致的。当然，性能问题分析不能仅凭借猜测和经验去武断的下结论，还是应该用工程的思维去分析排查，最后进行优化验证。

这篇文章，结合自己的经验，聊聊性能问题分析和排查在实践中的方法。

 

性能问题分析链

先看下面这张思维导图，是我在工作中遇到性能问题时常用的分析方法，我称之为分析链。

如上图所示，分析链应该是这样的(数据仅供参考)：

• 观察问题表现：测试环境，服务配置2C4G，20-200并发递增，并发达到100，RT飙升，20%错误请求；
• 寻找证据链路：即找到哪里出现了问题，比如带宽打满、内存使用率100%、大量请求超时报错、出现异常堆栈；
• 分析问题原因：为什么会出现这些问题？一般分析的时候是自上而下，即脚本-数据-场景-配置-代码-系统架构；
• 性能优化验证：利用监控和日志，先用排除法快速找到可能的原因(需要丰富的经验打底)，然后调试验证猜测。没问题的话修改问题后重新压测验证，并及时观察监控和日志，确认问题得到解决；

 

性能分析实践案例

以文章开头这位同学的问题为例，我们该如何进行分析呢？

首先，这个压测的场景中会加载静态文件，我们常见的静态资源主要有图片或者前端的一些页面；其次资源大小为10+M，那可以假设这个静态资源为图片或者短视频；问题描述中提到了Nginx用docker部署，静态资源挂载在Nginx，那么Nginx的存储资源需要考虑，为什么呢？

在压测过程中，一般都是模拟多个不同用户请求去访问URL的，如果每次请求都返回不同的图片，并发比较高的情况下，服务的IO压力会比较大。

还有一种情况需要考虑，就是压测集群到被测服务之间的网络带宽资源，如果带宽只有100M，那实际的传输效率理论上峰值只有12.5M/S。这种场景下就会出现一个问题：即使并发再高，它实际的TPS可能是<=1的。

很多测试同学在执行性能测试时常犯的错误就是不考虑实际的业务场景和被测服务的配置和网络带宽，无脑模拟高并发请求，这样做既不科学也不合理。

实际上应该考虑具体的业务场景，以及被测服务的配置，然后再设计脚本，比如电商业务常见的秒杀场景，这个时候可以模拟高并发。

在上述问题中，还有两点需要考虑：第一个是将比较大的静态资源挂载于Nginx，而比较合理的技术方案应该是静态资源或者大文件，用专门的文件存储服务，比如图片就可以存储于CND中。

第二点也是容易忽略的一点，为了提高性能，文件最好是先压缩再传输，然后在展示层解压，当然这样做的前提是对图片没有高分辨率要求。

 

网上很多文章介绍了压测工具如何使用，测试数据如何准备以及如何模拟并发的技巧，但是在我看来这些都是手段。

性能测试最重要的环节是性能需求分析阶段，在分析阶段就应该尽可能考虑到被测的业务场景特点，背后的系统架构和技术实现方案是否合理，是否存在潜在的性能瓶颈点。压测，只是验证的手段，而非验证的目的。

近几年大家都在提测试左移，除了质量内建和质量门禁，需求阶段的分析评估，以及准备兜底策略，其实是更重要的。