如何正确定义性能瓶颈

有同学留言问我：如何得到精确的性能瓶颈？

相比于问我怎么造测试数据，用什么压测工具监控工具的问题，我更喜欢这个问题。为什么呢，因为在我的理解里，工具的使用依然是入门难度，熟练使用哪个工具并不会改变性能测试这一技术实践的最终结果，差别只是效率高低的问题。而对于性能瓶颈的准确定义，反而会影响性能测试最终的结果，并对后续的性能优化验证产生直接影响。

这篇文章，聊聊我对于性能瓶颈的理解和实践经验。

性能测试和功能测试在本质上没有区别，大体的流程也没差，无非是分析需求，准备用例、执行用例、确认 BUG、跟进修复验证，最终出具测试结果/报告。两者的不同点在于，侧重不一样：功能测试侧重需求的正确实现，性能测试更注重系统的处理能力是否能支撑真实的用户访问。

在功能测试开展前，我们会分析需求，确认需求要实现的功能最终是什么表现形式，以便于设计测试用例和预期结果，性能测试同样如此。在性能测试开展之前，依然要分析需求，确认预期的性能指标，即当系统达到什么指标的情况下，可以支撑线上业务的用户访问，而性能瓶颈，对应的则是未达到预期性能指标。

网上充斥着太多的水文，讲了太多错误的性能测试方法，荼毒了不少人。比如用高并发把服务器资源使用率压上去，直到服务挂了，这个时候的性能测试结果就是所谓的性能瓶颈；再比如当 RT 明显上升和出现请求报错时，就到性能瓶颈了。诸如此类，误人子弟。

什么是性能瓶颈？一句话概括：在给定条件下未达到预期性能指标，就是性能瓶颈。

需求：创建订单场景，服务器配置 4C8G，预期性能指标是单机在 CPU 使用率 40%以下时，TPS>200&99RT<200ms。这个时候的预期性能指标是什么？

答案：单机 CPU%<40%+TPS>200+99RT<200ms，这就是预期性能指标。

其中的给定条件，业务场景是创建订单，服务器配置是 4C8G，环境配置是单机服务器。

分析完需求后，接着该做什么呢？按要求搭建压测环境，根据创建订单的业务场景准备对应的测试数据，然后找个压测工具编写脚本，同时部署好监控，以便压测时可以实时观察性能指标的变化。

如果在给定条件下，性能表现符合预期指标，那就是不存在性能瓶颈。如果性能表现未达到预期指标，就出现其他问题，比如请求超时、报错率较高、内存资源耗尽，则判断存在性能瓶颈。然后就是根据具体的问题具体分析，逐一排查，修复后再次进行压测验证，直至达到预期结果。

很多刚学习性能测试的同学都对性能测试有个误解，那就是我一定要把服务器资源压满，或者一定要让它出现 RT 拐点才表明到了性能瓶颈，其实并不是这样。

无论是功能测试还是性能测试，工作开展的前提一定是需求说明。通过需求分析确认测试场景，预期结果，然后针对性的设计测试用例，执行用例进行验证。至于你是手动点点点还是利用工具自动执行，本质上对测试结果没有影响。

当然，对于刚开始入门学习性能测试的同学来说，确实很容易犯一些基础的常识性错误，如果有一定的项目实践经验，就会知道性能测试比我们想象的要复杂得多。除了对技术的广度和深度有一定要求之外，对业务的熟悉程度，对需求和场景的分析理解能力，甚至在压测实施过程中的沟通和协调能力，也有较高的要求。