随着IT技术的飞速发展和企业互联网+业务规模不断扩张，IT架构经历了以数据计算为核心的C/S架构、以聚焦业务功能及服务化构建应用的经典互联网架构和如今整合IT资源和按需使用的云计算架构三个阶段。

与之同步发展的压力测试同样有三个发展阶段，从防火墙内的压力测试到基于云计算的压力测试，再到用户视角的外部压测，云智慧的压测宝就是第三代压力测试产品。而Apache JMeter作为一款大名鼎鼎的开源压力测试产品，在设计之初就被用来测试C/S结构的软件，其实现原理就是在防火墙内部产生压力来进行压测，测试目的也仅是对内网的系统硬件资源以及服务、数据库在内网并发负载下的性能表现。

继《云智慧压测实战分享之JMeter工具使用初探》和《云智慧压测实战分享之JMeter脚本录制实例》两篇内容之后，今天云智慧工程师为您带来的是《云智慧压测实战分享之JMeter场景设置与监控》，主要包含以下三部分内容：场景设置、场景运行和测试监听。

场景设置：

测试场景是测试过程中通常尽量模拟真实系统环境及用户操作而设计的场景，场景设计源于用户的真实操作，设计原则是贴近于用户实际操作，组合用户的各种操作到场景中来。JMeter是通过线程组的设置来完成场景设置的，有些复杂场景还需要与逻辑控制器配合。
JMeter 线程组实际上是建立一个线程池，JMeter根据用户的设置进行线程池的初始化，及在运行时做各种异常处理。下面我们用一幅图看一下线程组的一些参数：

名称：根据实际业务需求，最好有业务含义，与场景相符。
注释：可以随意设置，可以为空，但是为了以后方便使用，这里最好写上有意义的备注，和编程里的注释的目的是一样。
在取样器错误后要执行的的动作：就是线程组内某一个请求出错后的异常处理方式
继续：某一线程的某一请求出错后，继续运行，就是忽略本次错误继续执行；
Start_NextThread loop:进行下一次线程循环，类似于for循环中的continue；
停止线程：当某一线程失败或报错后停止本线程，类似于LoadRunner中的停止该Vu；
停止测试：某一线程某一请求失败后，停止所有线程，也就时停止本次测试，但不时立即停止测试，是在本场景中其他线程执行迭代结束后，停止本次测试；
stop Test Now：马上停止本次测试，不管其他线程是否执行结束；
线程属性：
线程数：可以理解为并发用户数，一个线程对应一个并发用户；与LoadRunner中的VU一致，只是LoadRunner中VU可以是线程，也可以是进程（以Http协议为例）；
Ramp-up period(in second)：线程启动开始运行的间隔时间，此处单位为秒，即所有线程多长时间内全部启动，假设线程设置为100（模拟100vu并发），Ramp-up period设置为10秒，那就是10秒内将100个线程启动，相当于每秒中有10个线程启动（100/10）；如果设置1，就是场景发起后1秒内全部启动100个线程。
循环次数：“永远”就是场景不结束就所有线程一直发起压测，如果想每个线程迭代多少次之后就停止压测，就可以填入具体的数字。
Delay Thread creation until needed：选择该项，线程在Ramp-up period的间隔时间启动并运行，如100并发线程，10秒的ramp-up period时间，那么1秒种启动10个线程并运行采样器中的请求。如果不勾选，测试计划启动所有线程（100个）为new状态，但不立即运行采样器（sampler）中的请求，是按照ramp-up period时间来运行的，如100个线程，ramp-up 的时间是10秒，那么每秒会有10个线程有new状态转为Running，并执行采样器中的请求。实际测试场景设置时，选不选该项都不会影响测试结果。二者的区别是勾选线程是在间隔时间内建立启动并运行，不勾选是先建立所有线程然后按间隔逐步执行。
调度器： 选择调度器可以控制场景执行时间或指定那个时间段执行，如秒杀场景就可以设置为某日某点某分开始执行，某日某点某分结束，具体调度器中各个参数如下：
持续时间：表示脚本持续运行的时间，以秒为单位，例如脚本模拟用户持续不断登录1个小时，你可以在文本框中填写3600。如果在1小时以内，结束时间已经到达，它将会覆盖结束时间，继续执行。 
启动延迟：表示脚本延迟启动的时间，在点击启动后，如果启动时间已经到达，但是还没有到启动延迟的时间，那么，启动延迟将会覆盖启动时间，等到启动延迟的时间到达后，再运行系统。例如你的测试场景需要再另外一个场景结束后开始，上一个场景需要10分钟后结束，那么你可以再启动延迟中设置601秒，点击启动，就可以在上一个场景结束后，开始本次测试场景； 
启动时间：表示我们脚本开始启动的时间，当你不想立即启动脚本测试，但是启动脚本的时间不会再电脑旁的时候，你可以设定一个启动的时间，然后再运行那里点击启动，系统将不会立即运行，而是会等到你填写的时间才开始运行。
结束时间：与启动时间对应，表示脚本结束运行的时间。
注意：如果我们需要用到调度器来设定持续时间，如果线程数不够多到持续时间结束，我们就必须将循环次数勾选为永远，如果线程组里面有其他的循环，我们也需将该循环次数勾选为永远。

在云智慧压测宝中场景设置就简单多了，选择好脚本和测试数据后，设置并发用户和场景运行时间及压力发起方式，平行还是坡度，压测宝能自动计算每秒启动多少VU并发，如上图所示。
场景运行：
JMeter的场景运行方式分为两种，一种是GUI可视化运行,测试者可以实时看到压测执行过程和压测结果，像LoadRunner的Controller一样；另外一种是非GUI模式运行，即通过命令行像执行Shell一样，在命令窗口运行。
JMeter的场景运行可以在本地运行（即单机运行），也可以是远程运行，不论是GUI模式还是非GUI模式都支持本地和远程执行。本机运行类似于LoadRunner中将本机做为Controller同时也作为Agent；远程执行类似于LoadRunner中将Agent安装在别的机器上。
通常在需要大压力的场景下，一台机器产生的压力不能满足测试需求，就需要多台压力机，这时就需要远程执行，如下图所示：

GUI运行：GUI方式是可视化，直接通过点击鼠标就可以控制场景的启动和停止，同时也能随时查看场景的运行状况，实时结果，测试线程数等。
1.本地运行的所有请求从一台机器发出，如下图，设置了4个并发线程：

运行的快捷菜单按钮是：

，本地运行点击按钮开始运行，或者通过运行菜单开始运行，如下图：

场景运行后，我们可以看到下图中的状态，时间00:00:01显示的是当前场景运行的时长，后面感叹号的图标是当前场景中是否有线程异常，0为没有线程异常，0/4中前面代表当前运行的线程数，后面的4代表共运行了4个线程。
，

在场景运行过程中点击，可以停止当前场景。
远程执行：
远程执行通常是在一台机器上的JMeter作为Controller，远程的多台机器（slave）作为负载生成器，JMeter控制台与负载机的通信是通过RMI方式来完成的。在负载机上运行Agent程序，首先启动jmeter-server，在JMeter控制机（Master）上点击启动远程控制机。
说到这里需要补充说明一下，在启动远程机之前需要在JMeter控制机上配置jmeter.properties文件，将远程负载机IP地址配置到控制台jmeter.properties文件中；如下图所示，将远程负载机的IP地址配置在Remote_hosts=配置项后面，多台机器用逗号间隔，如果没有制定端口的话，默认不配置端口。

注意：远程运行方式如果脚本有依赖的参数文件或Jar包等文件，需要先把这些文件拷贝到远程机负载机上，这点不是很人性化，云智慧的压测宝就不存在这样的问题，只要把参数传上就可以了。
非GUI方式运行：
非GUI方式是没有JMeter图形化界面，在命令行窗口通过命令来运行场景，之所以用非GUI方式运行，是因为JMeter可视化界面及监听器动态展示结果都比较消耗负载机的资源，在大并发下GUI方式往往会导致负载机资源紧张，对性能测试结果造成影响。当然这个影响不是影响被测系统如导致响应时间变大，处理能力减小等，而是影响负载机负载压力的产生，如非GUI方式可以产生200TPS的负载，而GUI方式只能产生140TPS的负载。当然如果资源比较充足的情况下，GUI方式更能直观实时了解测试场景运行状况。至于用哪种方式，个人认为根据实际情况选择，资源不宽裕的情况下选择非GUI方式，资源充足的情况下可以用GUI方式。
非GUI方式运行命令共两种方式，如下：
1、 jmeter –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
2、java –jar /apache-jmeter-3.0/bin/ApacheJMeter.jar –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
jmeter 非GUI方式下的各种命令行参数这里不在细说，大家可以根据帮助文档按图索骥。
测试监听：
性能测试监控的主要任务是获取运行状态、收集测试结果，测试结果有事务的响应时间、吞吐率、服务器硬件资源性能（CPU、内存、DISK I/O、网络等）指标及JVM使用情况、数据库性能状态等，这些在JMeter中是监听器负责监听的工作。
JMeter监听器比较多，如下图所示：

长时间执行测试计划使用的监听器主要是Summary Report 或者aggregate Graph (聚合报告)，也是今天主要介绍的内容。Summary Report以表格的形式显示采样结果，如果不同采样器（不同请求）使用相同的名字，那么测试结果在Summary Report中会统计到同一行，所以在给采样器命名时不要都为空或取相同的名字，根据实际业务进行命名。这个类似于LoadRunner脚本中的事物，如果事物名称一致，测试结果中不同脚本相同事物将被统计到一起，如下图所示：

Label：每个 JMeter 的 element （例如 HTTP Request ）都有一个 Name 属性，这里显示的就是 Name 属性的值；

Samples：表示你这次测试中一共发出了多少个请求，我的测试计划模拟 10 个用户，每个用户迭代 10次，因此这里显示 100；

Average：平均响应时间 —— 默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以 Transaction 为单位显示平均响应时间；
Min： 最小响应时间 在测试场景中采样器一次请求最小的响应时间；
Max： 最大响应时间 在测试场景中采样器一次请求最大的响应时间；
Error%： 本次测试中出现错误的请求的数量 / 请求的总数；
Throughput： 吞吐量 —— 默认情况下表示每秒完成的请求数（ Request per Second ）RPS或者是TPS。
上面字段基本上已经能够说明测试结果，当然测试者也可以根据自己需求添加一些需要监控的参数，点击config按钮，弹出下图中配置页面：

提示：保存的监听参数越多，对本机和负载机的IO产生的压力越大，所以并不是参数越多越好，够用就可以了。
Aggregate Graph(聚合报告)

在Aggregate Report中，会显示一行数据，共有10个字段，Label、#Samples、Average、Min、Max、Error%的含义和Summary Report一样，有差异的字段如下：
Median：中位数，也就是 50％ 用户的响应时间；
90% Line：90％ 用户的响应时间；
Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的TPS[Transaction per Second]；
KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec；
通过上面的介绍，可以看到Summary Report和Aggregate Graph(聚合报告)类似，只是 聚合报告更详细一点。说了这么多是不是觉得jmeter的监听器很复杂，所以还是压测宝更方便，不需要设置什么监听器，测试结果直接实时展现，如下图所示：

好了，今天就分享到这里，JMeter 还有很多内容，后面有机会再一一介绍，谢谢大家！