基于jmeter的性能测试（三）

一、 性能测试准备工作

1. 聚合报告

1.1 添加聚合报告

聚合报告可以统计运行结果，添加方式：添加->监听器->聚合报告。一个线程组一个聚合报告。

1.2 报告字段解析

（1） Samples：线程数
（2） Average：平均响应时间，单位是毫秒
（3） Median：中间响应时间，反应中等水平
（4） 90% line：响应时间从低到高排序，排在90%的响应时间，比如共有10个响应时间，排在第9个的响应时间，代表90%的响应时间都比这个时间短
（5） 95% line：排在95%的响应时间
（6） 99% line：排在99%的响应时间
（7） Min：最小响应时间
（8） Max：最大响应时间
（9） Error %：错误率
（10） Throughput：吞吐量，每秒处理了多少请求，单位是秒。计算方式：请求数/花费的总时间，总时间=造第一个人的开始时间+最后一个请求结束的时间，如果倒数第二个响应时间很长，可能要算倒数第二个请求结束的时间。
（11） Received KB/S：接收的网络带宽速度，计算方式：传输的文件大小（响应数据大小）/花费的时间
（12） Sent KB/S：发送的网络带宽速度，计算方式：请求数据大小/花费的时间

1.3 聚合报告导出

（1） 数据导出

• 点击浏览，选择一个文件保存路径（如果该文件名不存在，则会自动新建）
  

• 导出内容可以自定义，方法如下：
  

• 导出数据如下（如果使用Excel打开，可能会乱码，此时需要更改文件编码格式）
  

（2） 总结报告导出

• 点击save table data，然后自定义文件名，点击保存
  

• 导出后的报告如下：
  

2. 服务器系统资源监控插件

2.1 如何判断是运维问题还是开发问题

• 添加物理资源监控插件，在运行请求时，会动态监测CPU、内存等资源，刚开始性能比较低时，CPU压力比较小，当增加压力时，CPU会升高，如果性能不达标，CPU已经飙升到100%，就是运维问题，需要弹升资源。
• 内存和CPU一般在80%~90%，常见80%或85%，峰值的时候不要超过90%，需要留一些空间预防突发情况。

2.2 添加物理资源监控插件

添加方式：添加->监听器->jp@gc – PerMon Metrics Collector

2.3 监控插件配置

（1） 点击add row，在host/ip栏填入接口IP地址

• 一般会监控CPU、内存、磁盘、网络四个选项
  

（2） ServerAgent must be started：服务器必须启动。这是一个客户端和服务端的插件，如果需要监控资源，首先需要启动服务端。服务端启动后，客户端（jmeter）需要与服务器进行交互，这样才能获取到数据。
（3） 启动服务方法：
运行CMDRunner.jar包，启动jar包时指定端口为4445（在步骤1中使用的是8085端口）
命令：java -jar CMDRunner.jar --tool PerfMonAgent --udp-port 7777 --tcp-port 4445

可看到监控服务插件（JP@GC Agent）已经是启动状态
（4） 运行请求，查看监控曲线

可到服务器上查看内存值是否正确，使用free –m或top命令

2.4 判断CPU/内存/磁盘/网络是否超标

需要找运维了解这台机器的具体配置情况：

8核16G，带宽3-10M意思是：CPU是8核，内存是16G，带宽是3~10M

2.5 监控自己电脑

在运行时需要实现双向监控，避免自己本地的电脑不行。
（1） 解压缩ServerAgent压缩包，双击startAgent.bat启动服务

（2） 在jmeter里面添加监控行

二、 性能测试执行

1. 性能测试解析

1.1 需要做性能测试的场景

并不是所有接口都要做性能测试，只需要挑选代表性的、有大量用户会访问的、压力比较大的模块进行测试。

1.2 实例分析-考试平台

考试平台分为前台和后台，前台是学生考试的地方，后台是老师出试卷的地方。
（1）后台不用做性能测试，因为老师出试卷的场景本身压力不大。
（2）对于前台，有3个地方需要做性能测试：登录、开始考试、提交试卷，其他场景可以不考虑。
（3）其他场景：点击下一题，由于每个人答题速度不一样，压力会被分散开，如果1000个人同时点击开始考试性能都达标，则点击下一题的场景肯定也没问题。

1.3 实际测试执行

可以建3个线程组：第1组人-登录，第2组人-开始考试，第3组人-提交试卷。
（1） 首先需要调试脚本，建议线程属性设为3个1来调试。

（2） 脚本调通后，考虑性能目标

• 响应时间：2-5-8原则。
  • 2秒以内——性能比较好
  • 2~5秒——性能良，可以接受
  • 5~8秒——性能不好
  • 8秒以上——性能特别差
• 判断是否达标：在90%、95%、99%中挑一个，最常用的是99%，即99%的人响应时间在2秒以内就认为性能OK，同时错误率不能超过1%。

（3） 场景解析（最大吞吐量和最大并发量）
分为2个场景：一个是并发（最大并发量），一个是不并发（最大吞吐量）

• 不并发：淘宝聚划算，每天10点前10分钟优惠有效，这10分钟可能人比较多，但是整体是比较均匀的，此时不用加并发，只需看每秒能处理个数即可。比如10分钟共有5000个用户，吞吐量为5000/（10*60）
• 并发：前30名优惠，此时测试重点为最大并发量
• 吞吐看的是一段时间的处理水平，并发同一时间的处理水平

2. 基准测试

• 测试环境：在跑性能时保证只有一个人在操作服务器，且电脑本地无用的程序关掉，防止干扰测试结果。测试多次取平均值
• 不考虑并发的情况，看吞吐量。比如按每秒20个来验证，线程数：200，时间：10秒
  

测试结果：从吞吐量看，达到每秒20个，基准测试通过

3. 负载测试

基准测试OK后，在基准测试的基础上继续往上加
（1） 线程数300，时间10秒，每秒30个
（2） 线程数1000，时间10秒，每秒100个
（3） 测吞吐量时不建议让本地电脑不停的造人，实际需要测试的是接口调用。

• 一般的做法是快速造人，然后进行循环，如一秒造10个，即线程数100，时间为10秒，循环20次。
  

测试结果：从测试结果看出，95%的响应时间为99毫秒，还需要继续增加压力

什么时候结束：满足95%的响应时间在2000毫秒以内，错误率在1%以内吞吐量的最大值

4. 压力测试

响应时间超过2000毫秒或者错误率大于1%时继续往上加压力，可能会出现再加一点压力错误率直接升到80%，或者响应时间直接升到30秒，显示超时。看服务器会不会因为压力太大而挂掉

5. 稳定性测试

在调度器里面设置时间，让它一直跑，看稳定性如何

6. 并发测试

（1） 打开同步定时器
（2） 线程配置：已经测出来最大吞吐量之后，比如每秒处理500个请求，则线程数设为500，时间可以设长一点30秒（自己调整），循环次数1次
（3） 同步定时器配置：500一组，超时时间为0
（4） 此时不用太过关注吞吐量，重点关注响应时间和错误率
（5） 如果并发没有问题，可以不断往上加数据
查看测试结果时还需要结合表格查看每个请求的启动时间，看是否属于真正的并发，即所有请求在同一时间发出，或误差不大。因为并发也受本地电脑限制，人造好后，同时触发请求的命令需要电脑发号施令，所以，在做性能测试时最好使用高配电脑