同乐学堂
一、集合点
简单来理解一下，虽然我们的“性能测试”理解为“多用户并发测试”，但真正的并发是不存在的，为了更真实的实现并发这感念，我们可以在需要压力的地方设置集合点，每到输入用户名和密码登录时，所有的虚拟用户都相互之间等一等，然后，一起访问。
注意：
1.JMeter里面的集合点通过添加定时器来完成。
2.Synchronizing timer仅作用于同一个JVM中的线程。
1) 启动路径
2）用法
Number of Simulated Users to Group by:集合多少人后再执行请求（也就是执行的线程数）
注意：等同于设置为线程租中的线程数，一定要确保设置的值不大于它所在线程组包含的用户数。
Timeout in milliseconds：指定人数 多少秒没集合到算超时（设置延迟时间以毫秒为单位）
注意：如果设置Timeout in milliseconds为0，表示无超时时间，会一直等下去。
线程数量无法达到"Number of Simultaneous Users to Group by"中设置的值，那么Test将无限等待，除非手动终止。
3）如果希望定时器仅应用于其中一个sampler，则把该定时器作为子节点加入，如下图
定时器仅仅对HTTP请求1起作用，即仅在HTTP请求1执行前执行定时器，和HTTP请求2无关。
4)如果你希望synchronizing timer应用于多个sampler.
如下，执行HTTP请求1和HTTP请求2前都会执行同步定时器1、2。
当执行一个sampler之前时，和sampler处于相同作用域的定时器都会被执行；
注意点:
集合点的位置一定要在Sample(采样器）之前才能生效吗???”
在Jmeter中，timer是在sampler之前执行的。不管这个定时器的位置放在sampler之后，还是之前。
当然，如果有多个timer的时候，在相同作用域下，会按上下顺序执行timer，这个就需要慎重放置timer的顺序；不过，为了更好的可读性，还是建议将timer放在对应的sampler前面 或 子节点中；
5) 进行必要设置后，运行查看效果，通过结果树可以看到，请求是批量执行的。
可以观察开始执行的脚本，观察请求的增加数量趋势；或对比请求的发送时间.
补充: Synchronizing timer 仅作用于同一个JVM中的线程。
试想：
a.如果分布式测试时，synchronizing timer作用于所有jvm，那么jvm之间或者说监控jvm工作的部件就需要频繁通讯，确定线程的数量及状态等，然后集结了足够的线程后，又要发送信号让Jmeter来发送测试请求，中间存在延时，这样就无法模拟更真实的高并发了，而且这个东西还会消耗测试机器的一部分性能，会给测试结果带来负面影响；所以暂时是只支持控制单个jvm，如果后面有办法解决上面那些问题后，就可以实现控制多个jvm，控制总并发量；
b.如果分布式测试，并使用了Synchronizing timer，且设置的值是小于单个jvm的线程数量；但是，较难确保所有jvm都在同一时间点集结了同样数量的线程数，这样就很难下测试结论了，因为都不知道是多少并发下的性能表现；当然了，可以将线程的启用时间拉长，并将超时时间延长，这样就很可能会与同一时刻集结到足够的线程，达到超高并发的测试；所以，分布式测试与Synchronizing timer一般不是同时使用的；如果非要用，则需要慎重设置相关参数。
二、负载与监听
1. 场景设计
场景设计的原则：忠于用户实际操作，组合用户的各种操作到场景中来。
JMeter场景主要通过线程组设置来完成的，对于复杂场景还需要与逻辑控制器配合完成。
2.场景设置
JMeter线程组实际上是建立一个线程池，JMeter根据用户的设置进行线程池的初始化，在运行时做各种异常的处理。
参数说明：
√ 名称：可以随意设置，最好有业务意义
√ 注释：可以随意设置，可以为空
√ 在取样器错误后要执行的动作：也就是其中的某一个请求出错后的异常处理方式。
（1）继续：请求（Sampler元件模拟的用户请求）出错后继续运行；
（2）Start Next Thread Loop：如果出错，则同一脚本中的余下请求将不再执行，直接重新开始执行；
（3）停止线程：如果遇到请求（Sampler元件模拟的请求）失败，则停止当前线程，不再执行；
（4）停止测试：如果某一线程的某一请求失败了，则停止所有线程，也就是 听下整个测试；
（5）Stop Test Now：如果有现成的请求失败了，马上停止整个测试场景。
√ 线程属性：
（1）线程数：运行的线程数设置，一个线程对应一个模拟用户；
（2）Ramp-Up Period(in second)：线程启动开始运行的时间间隔，单位是秒；
（3）循环次数：请求的重复次数，选择后面的forever，那么请求将一直继续除非停止或崩溃；如果不选择forever而在输入框中输入数字，那么请求将重复指定的次数；
（4）Delay Thread creation util needed：勾选，线程在Ramp-up Period的间隔时间启动并运行；
Java线程相关知识：
（1）NEW：创建未启动，已经实例化，只是没有开始运行线程的Run方法；
（2）RUNNABLE：就绪状态，线程对象创建后，其他现成调用了该对象的start()方法，该状态的线程位于可运行线程池中，已经准备好了只等获取CPU的使用权，然后开始运行；
（3）RUNNING：运行状态，就绪状态的线程获取了CPU使用权执行程序代码；
（4）BLOCKED：阻塞状态，线程因为某种原因放弃CPU使用权，暂时停止运行（典型的如IO等待导致的线程处于BLOCKED状态）；直到线程进入就绪状态，才有机会转到运行状态；
（5）DEAD：死亡状态，执行完毕或者异常退出，线程生命周期结束。
√ 调度器配置：设置何时开始运行
（1）启动时间：测试计划什么时候启动，时间格式“2018/03/22 09:10:10”
（2）结束时间：测试计划什么时候结束，时间格式“2018/03/22 12:13:14”
（3）持续时间：测试计划持续多久时间，如果启动时间+持续时间大于结束的时间，那么此设置覆盖结束时间
（4）启动延迟：点击执行按钮后（此时间未T），仅初始化场景，不运行线程，等待延迟到时候开始运行线程。
3. 场景运行
JMeter的场景运行方式分为两种，一种是GUI（视窗运行，即我们可以看到的运行界面）方式；一种是非GUI方式运行（命令窗口）。
JMeter的场景运行基于运行架构分为两种，一种是本地化运行，即单机运行；另一种是远程运行。
JMeter非GUI运行的命令：
（1）java -jar %JMETER_HOME%binApacheJMeter.jar -n -t %JMETER_HOME%scriptJforum4-1-01.jmx -r -l result.jtl
（2）%JMETER_HOME%binjmeter -n -t %JMETER_HOME%scriptJforum4-4-01.jxm -l%JMETER_HOME%resultresults.jsl
4. 性能参数配置
5. 测试监听
性能测试监控的主要任务是获取运行状态收集测试结果，测试结果有事务响应时间、吞吐量及服务器硬件性能（CPU、内存、磁盘等）、JVM使用情况、数据库性能状态等。
5.1 JMeter监听器
常使用的监听器主要是Summary Report或者Aggregate Graph。
Summary Report以表格的形式显示取样器结果，如果不同取样器（不同请求）拥有相同的名字，那么在Summary Report中会统计到同一行，所以在给取样器取别名时最好不要为空，建议按业务功能来取名。
结果说明如下：
√ Label：取样器别名（或者说是事务名），比如我们提交一笔订单，那么取样器我们可以命名为“订单提交
√ #Samples：取样器运行次数（提交了多少笔业务）
√ Average：请求事务的平均响应时间
√ Min：请求的最小响应时间
√ Max：请求的最大响应时间
√ Std. Dev：响应时间的标准偏差
√ Error%：事务错误率
√ Throughput：吞吐率，常说的TPS
√ Recevied/Sent KB/sec：每秒数据流量包，单位KB
√ Avg.Bytes：平均数据流量，单位Byte
在Summary Report界面可以设置结果属性（包含哪些结果字段），点击
到下图所示界面。
到下图所示界面。
Aggregate Graph以表格形式显示取样器结果，如下图所示。
结果说明：
√ Lable：请求别名
√ Samples：执行了多少次取样
√ Median：响应时间中间值
√ 90% Line：90%事务响应时间范围
√ Min：最小响应时间
√ Max：最大响应时间
√ Error%：出错率
√ Throghput：吞吐量，可以理解为TPS
√ Received/Sent KB/sec：数据传输量，单位KB
全栈性能测试修炼宝典JMeter实战（陈志勇）
微信扫一扫，打赏作者吧～
