云智慧压测实战分享之JMeter场景设置与监控

随着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方式运行命令共两种方式，以下：
一、 jmeter –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
二、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 还有不少内容，后面有机会再一一介绍，谢谢你们！