教你五种解决性能测试的办法，建议收藏！

lsekfe

引言
　　很多做性能测试的同学都问过我这样一个问题：鱼哥(Carl_奕然)，你说性能测试的重点是什么?
　　我的回答很简单：瓶颈分析与问题定位。
　　在性能项目的整个周期，不管是脚本设计、脚本编写还是脚本执行，都还算简单。
　　难点在于如何定位瓶颈、分析瓶颈、解决瓶颈。
　　如果你不会性能分析，脚本设计得再好，脚本编写得再完美，分析不出问题所在，那都是白白浪费时间。
　　所以，这一讲，我们来学习：如何进行性能分析，学会了性能分析的思路，才能定位问题、分析问题，从而解决问题。
　　在性能项目中，我总结的性能分析思路，分5个模块，即性能分析5部曲，如下：
　　1、判断性能瓶颈
　　2、线程递增策略
　　3、性能衰减过程
　　4、拆分响应时间
　　5、构建分析决策tree
　　接下来，我就对这5部曲进行一一解释。
　　判断性能瓶颈
　　如何判断性能瓶颈，在整个性能测试过程中，这是让性能测试工程最苦恼的事情。如果无法准确的定位到性能瓶颈，那么对开发的协助能力就有限，从而无法快速的解决性能瓶颈。
　　而分析性能瓶颈，也是排查解决问题的第一步。如何进行问题分析，我先上一张图：

通过这张图，我们很直观的知道：这是一个很明显阶梯式增加的场景。
　　但是，请思考一下，我们是否能判断出拐点在哪呢（在性能测试过程中，都是要先找拐点，再定位问题）？
　　这时候肯定就会有人说在1300左右， 也有人认为在1500左右，还有人会说这明明就是在2000出现的拐点。
　　别着急，我们再看这张TPS图对应的ResponseTime（后面简称为RT）图：


看到RT图，是不是就会有人说在4.5就出现了拐点。其实以上这些对拐点的判断，都不合理（不能说完全不正确）。
　　如果要对TPS的增加控制非常准确的话，就需要找到TPS在增加时，那个明显而清晰的弧度，而不那个明显而清晰的拐点，这一定要注意，也是一定要记住。
　　但是，通过TPS图和RT图，我们还是可以判断出瓶颈在第二个压力阶段就已经出现了。
　　原因
　　响应时间增加了，TPS却没有增加的那么多，到第三阶梯时，TPS增加的就更少了，响应时间还在不断的增加。
　　所以，性能瓶颈就在不断的加剧，而越往后面的阶梯，这种现象就越明显，直到系统垮掉或手动停止掉。
　　根据上面的现象，我们的判断结果：
　　系统有瓶颈
　　瓶颈和压力有关
　　压力呈阶梯型，而且增长幅度在不断衰减