每个资深测试工程师,必须掌握的测试工具,熟练使用Jmeter能大大提高工作效率。熟练使用Jmeter后, 能用Jmeter搞定的事情,你就不会使用LoadRunner了。Jmeter 是一款使用Java开发的,开源免费的,测试工具, 主要用来做功能测试和性能测试(压力测试/负载测试). 而且用Jmeter 来测试 Restful API, 非常好用。

                                       From Jmeter中文官网

本文是Jmeter操作笔记,

本文是Jmeter操作笔记,

本文是Jmeter操作笔记。

【前文从理论角度对比了lock锁(Monitor)与读写锁(ReadWriteLockSlim)的差异和使用场景,尝试用Jmeter对lock、ReadWriteLockSlim压测】

启动Jmeter

通过点击jmeter解压目录.\apache-jmeter-5.4.1\apache-jmeter-5.4.1\bin\jmeter.bat 启动jmeter,



jmeter 链接redis并执行 jmeter压测redis_多线程

上图有一个默认的测试计划,没有任何内容。

线程组

线程组元件是任何测试计划的开始点,可以配置要模拟的用户数,所有的任务都是基于线程组。

右键单击(Test Plan)>Add> Threads(Users)>Thread Group, 将添加线程组。



jmeter 链接redis并执行 jmeter压测redis_java_02

区域一:在采样失败后怎么处理?

  1. Continue:继续执行接下来的操作;
  2. Start Next Thread Loop:开始下一次循环;
  3. Stop Thread:停止线程,退出该线程(不再执行此线程的操作);
  4. Stop Test:等待当前执行的采样器结束后,结束整个测试;
  5. Stop Test Now:马上停止测试;

区域二:线程属性

  1. Number of Threads(users): 线程数,相当于模拟的用户数量;
  2. Ramp-up Period(in seconds): 达到指定线程需要的时间,如果线程数是10, 时间设定为1s, 就是1s内尝试加载10个线程;

未指定ramp-up period ,也就是说ramp-up period为0,JMeter 将立即建立所有线程。

  1. Loop Count:循环次数,如果选择[Forever]则一直执行下去,直到手动停止。

旁白:  在某R周期内启动了N个线程数, 进行了L次这样的周期测试。
请求次数= 线程数 * 循环次数

  1. Duration:整个压测的时长

添加采样器

此次我们主要测试 [多读少写]的场景,故我们添加http请求采样器。

在特定线程组右键>Add>Sampler>Http Request:



jmeter 链接redis并执行 jmeter压测redis_jmeter 链接redis并执行_03

基本使用方式,一点就通。

添加侦听器

通过侦听器 监听采样结果:线程组右键>Add>Listener>[****],

这里添加几个有效常见的侦听器:View Results Tree、Summary Report、Aggregate Report、Aggregate Graph



jmeter 链接redis并执行 jmeter压测redis_java_04

压测过程

在一个线程组内的线程是依次执行的,我们建立两个线程组分别测试

(读写比1:1)

压测时长:4分钟

每秒尝试启动300线程不断循环

http://localhost:5000/rwlock?key=aa&value=ss

1

http://localhost:5000/rwlock?key=aa&value=ssss

1

http://localhost:5000/monitorlock?key=aa&value=ss

1

http://localhost:5000/monitorlock?key=aa&value=ssss

1

jmeter 链接redis并执行 jmeter压测redis_压力测试_05

jmeter 链接redis并执行 jmeter压测redis_多线程_06


(读写比10:1)



jmeter 链接redis并执行 jmeter压测redis_jmeter_07

jmeter 链接redis并执行 jmeter压测redis_jmeter_08

Label :各个模拟测试的名称
Samples :各个测试的样本总数
Average :每个请求的平均响应时间
Median :中值,即50%请求的平均响应时间
90%Line :90%请求的响应时间
Min :最小响应时间
Max :最大的响应时间
Error% :错误响应的概率,即无法响应的概率
ThroughPut :吞吐量 – 默认情况下表示每秒完成的请求数(Request per Second)。
KB/Sec :每秒从服务器端接收到的数据量。

貌似性能基本没差异,====》 到Stack Overflow走一圈,    类似问题

https://stackoverflow.com/questions/4217398/when-is-readerwriterlockslim-better-than-a-simple-lock

There's no contention in this program. The Get and Add methods execute in a few nanoseconds. The odds that multiple threads hit those methods at the exact time are vanishingly small.

这个压测中没有争用,_dict.TryGetValue 是o(1)的复杂度,速度很块,多个线程在某时刻命中这个方法的概率极小,整个api代码块耗时几纳秒,压测结果12ms,绝大部分都是在网络上, 貌似要写代码测试了。

真是一个悲伤的故事,本文最终沦落为#JMeter操作笔记#。

筒靴们有其他意见或者想法,请留言赐教。  

源码地址 https://github.com/zaozaoniao/RWLOCKTest