JMeter+BlazeMeter+Metersphere压力测试踩坑实践

背景：在进行性能测试之前，我们需要了解需要模拟的场景，影响性能的因素、软硬件环境。根据最近一次的压力测试，把测试过程中遇到的问题以及测试过程进行总结。

测试需求：需要模拟用户登录操作进行测试，登录成功之后，提取浏览器session，进行第三方应用跳转动作。整个流程需要3-4个接口才能完成，一次完整的动作流程需要共享session。

需要达到的效果：数据库中存有200万的数据量，不同用户并发登录+应用跳转TPS>5000。

01 脚本录制

测试之前需要进行脚本录制，研究了几种浏览器录制脚本的工具最终选择了chrome插件BlazeMeter进行脚本录制。相比于BalazeMeter，BadBoy工具近几年没有更新，只支持IE浏览器。而Jmeter自带的代理方式录制脚本，需要使用火狐浏览器设置jmeter代理，使用也不方便，设置代理后录制脚本过程中会影响服务器自身插件、脚本校验等功能，在录制过程中往往会遇到一些问题导致服务访问报错，而且录制的脚本还需要修改过滤才能提取出真正需要压测的脚本。BalazeMeter可以录制浏览器的操作，直接提取jmeter脚本，通过域名筛选，提取出有效的脚本：

 通过登录之后，应用跳转，在BalazeMeter中查看保存的脚本dev.*.360.cn域名的三个脚本为登录、初始化、获取应用列表的脚本。其他为跳转到华为应用的脚本。

 通过BalazeMeter导出Jmx文件，可以过滤域名（dev.*.360.cn识别成了undefined，这个没有关系，只要能识别就可以）由于压测对第三方应用会造成很大压力，因此之后调整了测试方案，即只提取自己服务器相关的接口就可以了。选择undefined.undefined域名，保存jmx文件，至此，测试脚本就生成了。

 Jmeter打开脚本可以看到设置的用户代理：

02 数据构造

导入jmeter脚本，在BalazeMeter录制的脚本中，直接使用已经配置好cookie管理。

Same user on each iteration默认为勾选状态，相同用户共用session，请求不会返回session信息。

要模拟多用户并发，需要构造大量的数据，jmeter在升级以后可以通过配置关闭Same user on each iteration共享，一个用户参数设置多并发就可以模拟多个用户。

为了更真实，我在数据库中通过脚本调用先添加了2000个用户，通过csv文件导入jmeter，反复调用线程模拟不同的用户。

03 测试优化过程

服务器依赖redis和mysql，服务器性能配置、数据锁、登录密码验证机制也是影响压力的主要因素，需要一个持续的测试、调优过程才能达到最终的效果。

刚开始调试脚本，使用单机版Jmeter GUI模式进行测试，为了方便实时观察持续加压接口请求响应时间、响应结果的变化。

漫长的测试优化过程就开始了。

第一次脚本调试，先设置较小的线程，设置1000个线程并发，手动循环执行线程，执行几次之后发现吞吐量（qps）<400,执行几次之后，错误率持续上升：

这对QPS>5000的要求差的太远，起初怀疑客户端资源不够导致的QPS上不去，找了多台客户端，使用GUI以及非GUI方式测试脚本，发现运行一段时间后，出现大量的502等错误。因此排除了客户端的问题。

通过服务端查看CPU，发现8核16G服务器15个pod cpu、数据库CPU在压力请求时瞬间打满。

从服务器CPU、内存参数来看，理论上不应该这么小的压力瞬间就出问题。

后来经过研发分析代码，发现代码中的数据库、redis锁以及密码验证机制会影响性能，为了进一步确定问题，搭建了同样的环境，重新编写了单纯的访问接口，进行压力测试，发现单纯的接口访问，在单pod环境下进行压力测试qps能达到1.5万以上：

经过分析，还是代码逻辑影响性能很大。

又经过代码调整，对登录接口进行优化，分别对优化前的login接口和优化后的loginR接口进行单pod压力测试，做性能对比：

发现loginR QPS单pod>1000,而login接口QPS<200。性能还是有很大差别。

之后优化接口后，同时扩大副本数量进行压力测试，单客户端的jmeter也不能满足QPS>5000的性能压测，之后采用metersphere进行压测,线程并发最大设置为10000，用四个压力节点进行测试。

 发现qps不是按照指定目标成倍提升的，持续一段时间后，错误率明显提升。

 观察redis发现，redis分布中，有很多响应超时的现象,redis内存占用率很高：

 之后调整redis，扩大集群方式，调整redis读取锁时间、内存释放配置等重新进行测试。经过不断的调整，最终qps达到>6000的效果。

 04 后续

数据库数据增至200万，发现登录接口qps>9000qps，与之前的测试结果不符：

 经服务端分析，没有读取到数据库，修改后发现数据量为200万时，qps与小数据量差别不大仍为>6000qps。

之后又做了读写并发压力测试，写入测试的时候，为了避免数据冲突，通过beanshell前置脚本生成不同的用户，保证每次执行都是插入新的用户修改后压力测试读写并发>6000qps。

总结：压力测试过程中影响性能的因素很多，并发线程的数量，数据量大小，redis、mysql数据库配置、程序处理逻辑、内存、CPU配置等都会对压力有影响，需要针对不同场景进行测试、对比，发现影响性能的因素，通过不同的并发场景观察CPU、数据库、redis压力，响应时间的变化，找到程序执行的痛点，达到提升性能的效果。测试过程中也要观察服务端线程是否按照预期正常执行，防止遗漏处理逻辑导致测试数据不准确。

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！