JMeter性能测试之负载与监听实战

场景设置

JMeter 线程组实际上建立了一个线程池，JMeter 根据用户的设置进行线程池初始化，在运行时做各种运行逻辑处理。如途中所示，我们先看看线程组中的参数说明：

• 名称：可以随意配置，最好有业务意义。

• 注释：可以随意配置，可以为空。

• 在取样器错误后要执行的动作：也就是其中的某一个请求出错后的异常处理方式。
  （1）继续：请求（Smapler元件模拟的用户请求）出错后继续运行。我们在大量用户并发时，服务器偶尔错误是正常现象，比如服务器由于性能问题不能正常响应或者响应慢，此时出错我们正要记录下午，作为有性能问题的依据。
  勾选此项后，后面的请求将继续执行。
  （2） Start Next Thread Loop：如果出错，则同一脚本中的余下请求将不在执行，直接重新开始执行。
  （3）停止线程：如果遇到请求失败，则停止当前线程，不再执行。
  （4）停止测试：如果某一个线程中的某一请求失败了，则停止所有线程，也就是停下整个测试。但是每个线程还是会执行玩当前线程组内的所有请求才会停止。比如线程A正在执行登录的操作，然后此时其他线程中某一个线程出错了，那么线程A也会执行完登录，并且执行发布评论的请求后才会停止。
  （5）Stop Next Now：如果有线程执行失败了，马上停止整个测试场景。

• 线程数：运行的线程数设置，一个线程对应一个模拟用户。

• Ramp - UP Period（in second）： 线程启动开始运行的时间间隔，单位是秒。即所有线程在多长时间内开始运行。比如我们设置线程数为50个，此处设置10秒，那么每苗就会启动 50 / 10 ，5个线程。如果设置为0秒，则开启场景后50个线程会立刻启动。

• 循环次数：请求的重复次数，选择后面的 forever，而在输入框中输入数字，那么请求将重复指定的次数，比如输入 1，那么请求将执行一次，执行0次无意义，所以不支持。

• 调度器配置：如何设置开始运行

• 启动延时：顾名思义，设置多长时间后，开始执行线程组

• 持续时间：测试计划持续多长时间

运行场景

JMeter 的场景运行方式分为两种，一种是GUI（视窗运行，即我们可以看到运行界面）方式；另一种是非GUI方式运行（命令窗口），在Windows中我们可以在命令窗口运行。

JMeter 的场景运行基于运行架构分为两种，一种是本地化运行，即单机运行；另一种是远程运行。不管是GUI方式还是非GUI方式都支持本地运行与远程运行。下面我们以Windows系统下的JMeter为例讲解场景运行。

GUI运行

GUI方式由于可视化，对于我们来说更直观，鼠标点击就可以控制启停，也方便我们实时查看运行状况，比如测试结果、测试线程数等。

1. 本地运行
   本地运行即只运行本地一台 JMeter 机器，所有的请求从一台服务器发出，如下图所示，我们GUI方式本地运行，我们启动4个线程。
   
2. 远程运行
   远程运行是用一台 JMeter 控制机（Master）控制远程多台机器（Slave）来产生负载，JMeter 控制机与远程负载机的通信是通过 RMI 方式来完成的，在负载机上运行Agent程序（启动命令是 %JMETER_%\bin\jmeter-sever.bat),在 JMerer 控制机（Master）上单机运行键，运行远程负载机。_________________________________________________________
   大家可以再 %JMETER_HOME%\bin 目录下找到 ApacheJMeter.jar 与 jmeter-server.bat 两个文件。我们通过运行 jmeter-server.bat 来启动 Agent，Agent 程序是由 ApacheJMeter.jar 中的程序开实现的。旧版本的 jmeter 在远程通信时需要指定端口，当我们用 2.11 版本已经不需要指定端口了，JMeter 控制机会自动探测，只要先启动远程负载机上的 Agent，JMeter 控制机在开始执行测试计划，就会自动连接，不过在连接之前先告诉 JMeter 控制机，让他去尝试连接哪些机器，这个告诉动作是通过配置文件来完成的。打开jemter.properties 文件，所有 “romete_hosts”关键字，可以找到如下内容：
   

我们在 “remote_host=”后加上远程JMeter 负载机IP即可（推荐用IP而非机器名），多个机器之间的IP以逗号隔开（修改 jmeter.properties 文件需要重启 JMeter 才可以生效）。上面图中我们把remote_hosts中的两台机器都作为远程负载机，虽然127.0.0.1就是本地JMeter机器（也就是控制机），但是我们远程场景时还是会把本机机器当做远程机器（除非本地机器仅做控制器，不运行脚本），但是本地也需要启动 Agent（双机%JMETER_HOME%\bin\jmeter-sever.bat运行）。运行界面如下

如图，次 Agent 被用来连接的端口是52634，192.168.213.是本机IP，在配置时填写的是127.0.0.1，这并不矛盾。

注意：远程运行的脚本如果有参数话文件，脚本有依赖包，需要手工把这些参数文件、依赖包拷贝到远程机器上，这也是JMeter的一个不灵活的地方。即使是 LoadRunner 这样昂贵的商业工具，也不能自动化把依赖包拷贝到远程机器上，也需要配置。

非 GUI 运行测试

非 GUI 方式是没有JMeter页面的，我们在命令窗口通过命令来进行运行场景。之所以要非GUI方式运行是因为 JMeter 可视化界面及监听器动态展示结果都比较消耗负载机资源，在大并发情况下 GUI 方式往往会导致负载机资源紧张，会对性能结果造成影响。当然了，这个影响并不是说被测系统的性能受到影响，比如响应时间变大之类的，而是影响了负载量的生成，比如非 GUI 方式运行 100个线程产生 100TPS负载，而GUI方式只产生了 80 TPS 的负载，如果一台机器只能支持100个线程运行，那么我们只能多加机器进行测试计划，这样一台负载机变为两台。所以我们推荐用非GUI模式进行性能测试，另外在测试执行时，提醒大家关注负载机性能，可以多架设几台JMeter负载机来减轻单台负载机的压力。非GUI方式虽然不显示页面，但也会以符号形式周期性显示执行结果，对负载机的资源消耗会小一些，所以同等条件下非GUI方式的JMeter机器能够产生负载会比GUI方式的JMeter产生的负载大一些。

JMeter非GUI运行的命令如下：

（1）java -jar %JMETER_HOME%\bin\ApacheJMeter.jar -n -t %JMETER_HOME%\script\test.jmx -r -l result.jtl

(2)%JMETER_HOME%\bin\ApacheJMeter.jar -n -t %JMETER_HOME%\script\test.jmx -l %JMETER_HOME%\result\results.jtl

这两种方式都可以运行测试计划，JMeter 运行测试计划实际上是通过运行 ApacheJMeter.jar 来完成的。

性能测试参数配置

在场景运行时，我们提到了JMeter GUI模式下会比较占用资源，其实不管是 GUI还是非GUI，都会占用一定的资源，那我们有没有什么办法提高负载机性能呢？既是是纯Java开发，当然我们也可以调整其性能参数，让其在Java虚拟机上运行起来更顺畅，效果更高，下面我们以jdk 1.8.0_45版本为例。

打开%JMETER_HOME%\bin\jmeter.bat，找到类似如下的内容：

set HEAP：设置JVM堆大小，-Xms512m，设置初始堆大小512M，-Xmx设置最大堆大小。还可以用-Xmn来设置年青代大小，官方建议年青代(-Xmn)大小是最大堆(-Xmx)大小的3/8 （实际可以大一些，通常可以1/2）

set NEW：设置年青代大小，-XX:NewSize=256m 设置年青代初始内存大小，-XX:MaxSize=512m设置年青代最大内存。-Xmn与-XX:MaxSize有重叠，为了方便，只设置-Xmn即可，一般设置-Xms和-Xmx一样大，避免年青代初始内存占满后扩充空间时内存中数据迁移导致的性能影响。

set SURVIVOR：年青代分为两个Survivor区(S0和S1)和一个Eden区。-XX:SurvivorRatio=8设置Survivor与Eden大小的比值，S0和S1占年青代内存的2/(2+8)即1/5，eden占4/5。-XX:TargetSurvivorRatio=50%表示Survivor区的实际使用率为50%，调整Survivor的占用比率可以提高Survivor的利用率，最大为90%。

set TENURING：-XX:MaxTenuringThreshold=2，年青代晋升年老代周期（经过多少次GC还存活），默认值是15。

set PERM：-XX:PermSize=64m设置持久代初始大小为64M，-XX:MaxPermSize=128m设置持久代最大为128M，-XX:+CMSClassUnloadingEnabled，设置年老代CMS收集器对持久代进行垃圾回收。

set DUMP：-XX:+HeapDumpOnOutOfMemoryError，设置当内存溢出时Dump内存信息，这样好处是JVM崩溃后方便查看堆信息进行问题分析，找到内存溢出的原因。

测试监听

性能测试监控的主要任务是获取运行状态收集测试结果，测试结果有事务响应时间、吞吐量及服务器硬件性能（CPU、内存、磁盘等）、JVM使用情况、数据库性能状态等。在JMeter中监听器承担监听的工作，JMeter的监听器可以统计吞吐量、响应时间等指标、下面我们讲解一下常用的监听器、

JMeter监听器

JMeter的监听器比较多，长时间执行测试计划使用的监听器主要是Summary Report 或者 Aggregate report。

• Summary Report

Summary Report以表格的形式显示取样器结果，如下图所示，如果不同的取样器（不同请求）拥有相同的名字，那么在Summary Report中会统计到一行，所以在给取样器取别名的时，最好不要为空，建议按业务来取名。

在Summary Report界面可以设置结果属性（报错哪些结果字段），如图
上图中我们可以看到有些字段是被默认选中的，这些字段已经能够基本说明我们的测试结果，在长时间的运行时值只记录这些字段即可，并且利用于提高负载机的性能（字段保存的越多，磁盘的IO就越大，写磁盘是物理操作，对负载机的IO会产生影响，千万别让负载机IO产生性能瓶颈）

下面我们来解释一下，Summary Report中的结果字段分别对应的是什么意思。

• Lable：取样器别名（或者说是事务名），比如我们提交一笔订单，那么取样器我们可以把命名为“订单提交”

• Samples：取样器运行次数（提交了多少笔业务）

• Average：请求（事务）的平均时间

• Min：请求的最小响应时间

• Max：请求的最大响应时间

• Std.Dev:响应时间的标准差

• Error%：事务错误率

• Througput：吞吐率，通常我们说TPS

• KB/sec：每秒数据流量，单位KB

• Avg.Bytes：平均数据流量，单位Byte

• 2、Aggregate report
  Aggregate report 以表格的形式显示取样器结果

  1、Lable：请求别名
  2、Samples：执行了多少次取样
  3、Average：平均响应时间，单位毫秒。注意，这个平均值是所有请求的响应平均值。
  4、Median：响应时间中间值
  5、90% Line：90%事务响应时间范围
  6、Min：最小响应时间
  7、Max：最大响应时间
  8、Error%：错误率
  9、Throughtput：吞吐量，TPS
  10、KB/sec：每秒数据流量，单位KB

开源监听插件

总的来说JMeter的监听器还算完整，但是比一些商业性能测试工具来讲，图形化结果还是有所欠缺，作为开源性能测试工具，开源社区弥补了这个缺口。Jmeter Plugins 增加了众多的监听器，图形化丰富，功能强大，而且还可以监听服务器硬件性能（CPU、内存等），这个之后会出相关博客具体去将这一块。