Jmeter 使用详解、性能压测分析与性能优化思路

背景

辣鸡公司，测试人员都没有，新开发的接口需要做性能测试，只能由开发人员来做了。我上一次用Jmeter还是大三时学《软件测试》糊里糊涂弄的，都没玩明白。哎，欠的迟早要还，于是恶补了一下性能测试的知识与Jmeter的使用方法。这可能不是写得最好的Jmeter文档，但一定是非常细致的。 本文适用于完全不会用jmeter或使用步骤不清晰的小伙伴快速上手，不适用于大佬级别查漏补缺。

下载

可以直接到jmeter官方地址下载，点击一下图中框框的地方就可以弹出下载了。文件大小80多m，下载速度基本维持在200多kb，建议先下载。

运行

jmeter是免安装的，下载后解压，进入bin目录下，双击jmeter.bat即可运行图形界面。

框架搭建

1. 语言设置
   jmeter默认语言为英语，若要修改可在 Options -> Choose Language -> Chinese(Simplified) 中改成中文。但是，我并不推荐这么做。每次重启jmeter都会变回来英文，与其设置不如适应。在文中我也会以英文界面作为教程。
   
2. 创建线程组
   右键TestPlan的字体区域（空白区域无效），点击 add -> Threads(Users) -> Thread Group
   
   这样就出现了一个线程组，这是用来控制请求的并发数的。详细设置往下看，当前只做框架搭建。
   
3. 右键Thread Group，选择 Add -> Sampler -> HTTP Request
   
   层级上出来了HTTP Request，用于配置接口信息
4. 右键HTTP Request，选中 Add -> Assertions -> Response Assertion
   
   这是断言判断机制，目前添加的是响应断言，用于判断返回结果是成功还是失败。
5. 右键HTTP Request，选中 Add -> Config Element -> HTTP Header Manager
   
   添加请求头配置，如果不做这一步，请求报文中的参数将会无法以正确的格式解析。
6. 右键HTTP Request，选中 Add -> Listener -> View Results Tree
   
   用于查看结果响应报文是否正确
7. 右键HTTP Request，选中 Add -> Listener -> Summary Report
   
   用于查看总体性能信息
8. 完整框架结构类似于此
   

补充请求信息

1. HTTP Request 信息补充

参考于下面我的配置，都比较简单，和使用postman差不多。需要注意的时候，传参时，Body Data与Parameters只能二选一。下图所示使用的是Body Data，直接配置json格式报文即可。

2. HTTP Header Manager信息补充

需要配置Content-Type与Connection 否则会无法识别上面Body Data中传输的报文

3. 配置Response Assertion

响应断言，用于区分系统出错的报文

这里选择的Not代表，当系统收到下面配置的报文之后，将其识别成响应出错。复制一段错误报文后，在Patterns to Test 栏目下，点击Add，将报文粘贴进去。或者直接点击Add from clipboard。

连通性测试

配置信息都已经完成了，接下来先要测试是否能访问通接口。在Thread Group中，先配置发送一个请求，如果一开始没改过的话，这里应该不用改

点击执行

随后到 View Results Tree中，查看结果。可以看到案例中，我的系统访问是通畅的。

图中我的响应报文的应该被归类到错误里的，但是结果却显示了访问成功，jmeter默认判断Response code 为200即表示访问成功。这就是响应断言没做好，应该要把这段报文添加到Response Assertion中。

开始测试

确保接口访问无误后，开始进行性能测试。先将Thread Properties中的配置调整一下，可参考于我的配置，这里的配置的含义是不间断并发5个，你可以理解成发了5个请求后又立马发送5个请求这样。先点击clear all 再点击run，否则前面的统计结果会影响了本次执行的结果统计。

我们关心的数据，主要是有红框的内容

• 执行时间：性能压测一般都会持续一段时间，如10分钟
• Samples：这个表示已发送请求的数量
• Average：平均响应时间
• Error % ：系统出错率，前提是响应断言一定要做好
• Throughput：吞吐量，单接口的情况下，吞吐量非常接近于tps，这个是非常重要的参考数据

性能监控

在持续压测到一定时间后，tps趋于稳定状态，这个时候需要考虑加压。加压并不是说随便加，加到返回来一大堆error就是对了。需要考虑服务器的cpu与内存的占用率，一般而言，cpu占用率与内存占用率不建议超过80%，一方面是运维设置的阈值，一方面是机器性能到了80%就容易出错。
如果是linux服务器，可通过top命令查看，用100 - id 的数值就是当前cpu的占用率

如果是windows系统，打开cmd，执行resmon

调整线程数量（users），同时监控cpu占用率，当cpu占用率到达近80%时，停止调整

持续压测，等待tps的变动趋于稳定后，这就是接口的性能数据了。

性能优化

若前面的压测结果不符合你的预期，需要优化性能，应该着重考虑如下几点

1. 数据库慢查询语句检查与索引优化 （有所提升）

2. 加入缓存 （非常显著）

3. 日志优化（非常显著）

日志等级调整为INFO，debug级别会对性能有较大的影响。
1

4. 若上述方案都无法解决的话，则需要配合工具来检查具体的慢线程

jconsole、arthas、nmon