一、背景

随着各行各业都变得越来越卷，测试人员在压测的过程中，也不仅仅只是一个使用工具脚本施加压力的角色，而需要把自己变得越来越专业，将各类性能测试知识应用于压测实践中，从而达到在整个压测的过程中，测试的作用相比以前能有比较明显提升的效果。

今天以第三人称的口吻，主要列举几个在压测中实际发生的案例，希望能通过这样的方式，有更直观的感受，对后续想深耕性能测试方面的同学有所帮助。

案例一：分布式压测以前：

研发：接口TPS上不去，增加线程数

测试：好的，从200增加400线程

研发：怎么TPS还是没什么变化呢，接口响应时间也很快

测试：额…我也不太清楚，我换成2台压力机试试

a few moments later…

测试：额，TPS真的上来了哦~

研发：那为啥你1台压力机的时候上不来呢？

测试：我也不知道哦，不管了嘛，反正已经压上来了

研发嘀咕：他的压测脚本不会有什么问题吧…

现在：

研发：接口TPS上不去，增加线程数

测试：好的，从200增加400线程

研发：怎么TPS还是没什么变化呢，接口响应时间也很快

测试：额，可能是压力机瓶颈，我去看看压力机的资源情况

登录zabbix监控平台, 查看压力机的CPU、内存、磁盘、网络使用情况：

测试：网卡流量打满了，压力机网卡单网口流量上限2个G，我们接口返回的数据量太大了，大并发压测时把单台压力机的网卡流量打满，我需要换成多台压力机分布式压测。

换成多台压力机分布式压测后，TPS果然上去了。

研发：666666…

案例二：按比例混合压测以前：

研发：我们来个混合压测吧，两个接口按比例1:9发送请求到服务器

测试：额…我试试吧

于是两个接口分别执行压测，1个接口设置线程数100，另外1个接口设置线程数900，同时点鼠标执行压测。

a few moments later…

研发：耶，不对呢，咋请求量不是1:9呢？

测试：额…应该差不多吧，凑合着看吧，差不过有那个效果就行

研发嘀咕：…这小子到底会不会哦…

现在：

研发：我们来个混合压测吧，两个接口按比例1:9发送请求到服务器

测试：好，稍等我设置一下

于是一个jmx文件里放上这两个接口，使用jmeter吞吐量控制器，设置1000线程数，按比例10%和90%分配给接口1和接口2，执行压测。

a few moments later…

研发：嗯，可以可以，请求比例确实是1:9的比例，接口性能良好，压测通过~

案例三：Arthas排查接口性能问题以前：

测试：接口响应时间很长呢，研发，看一下呢

研发：我看看呐…

a few moments later…

研发：还没找到原因，硬件资源看起来是没什么问题的，我再看看调用链

a few moments later…

研发：调用链也没太大问题，好像是我自己接口代码耗时比较长，我再检查检查代码

a few moments later…

研发：好像是这段日志代码的问题，我注释下日志，发版再试试看

a few moments later…

研发：发好了，测试，来，再试一下. 测试…我去，居然睡着了

测试：啊? 改好了吗？哦，我再压一下试试…

研发嘀咕：哎，要测试有啥用，我自己点一下jmeter也行啊…

现在：

测试：接口响应时间很长呢, 研发，来，运行Arthas, 我们trace下接口代码，看看哪里耗时长呢

研发：哟，你还晓得Arthas哦，来哇，看一下

trace接口代码发现，耗时最多的地方是输出日志的这行代码，日志内容较多，造成日志打印耗时长，进而在大流量并发下造成接口性能下降。

测试：我去…说了多少遍了，大哥，本地调试完之后不用的日志要及时注释掉，看吧，又是日志的问题

研发：哎，忘了忘了，我马上改一下

a few moments later…

研发：发好了，来再试试

测试：可以了，TPS明显上升，下回不要再踩日志的坑了哦

研发：嗯嗯，好

以上就是本次的全部内容，如果对你有帮助，欢迎关注我的微信公众号：程序员杨叔，各类文章都会第一时间在上面发布，持续分享全栈测试知识干货，你的支持就是作者更新最大的动力~