标签：abr 求导 activate 获取 新手 out jmeter 研究 nbsp
1.开始之前，先介绍下压测的一些基本插件:线程组常用分为三类:user thread , step thread ,ultimate thread :
user thread :最通用的最原始的线程实现；分为循环实现线程，可以实现线程delay延时；
step thread :能够实现一些较复杂场景，比如常见爬坡类类型，以及持续在线场景
This Group will start 10 threads：这次的测试总共会起10个线程。 First , wait for 0 seconds：等待0s后开始起线程，也就是不等待直接起线程。 Then start 0 threads；从0个线程开始持续增加。 Next，add 2 threads every 3 seconds：每增加2个线程后会运行3s，再起余下的2个线程，再运行3s，以此类推。 Using ramp-up 6seconds：前面每起2个线程的时候花6s，与上面结合起来即6s内起2个线程，运行3s，然后再再6s内再起2个线程，再运行3s，以此类推。 Then hold load for 30 seconds. ：全部的线程起来后，运行30s 后开始停止。 Finally , stop 2 threads every 1 seconds：最后停止线程，2个线程停一次，等1s再
ultimate thread:
参数含义解释: Start Threads Count：当前行启动的线程总数 Initial Delay/sec：延时启动当前行的线程，单位:秒 Startup Time/sec：启动当前行所有线程达峰值所需时间，单位:秒 Hold Load For/sec：当前行线程达到峰值后的稳定加载时间，单位:秒 Shutdown Time：停止当前行所有线程所需时间，单位:秒
2。关于同步定时器syn timer:
它有两个参数:1.模拟用户组数量我这里把他称为集合释放阈值意思就是当你想实现用户达到一定数量时一起同时请求目的，他会根据你的 timeout时间设置决定什么时间发送已经集结的请求requests
你需要注意的有以下:1.模拟用户数量的值不能够大于线程组user thread 的线程数所填写的值，其次对于syn timer 的超时时间为0表示定时器会等到模拟用户数达到设置数量才会一次发出所有请求，非0时，如过设置时间内还未达到集合要求数量，将不会在等待后面还未到达请求，直接发送所有已到达requests;
2.如果你的模拟用户组数量也就是集结数量默认为0，他会按照use thread 线程数进行等待，对于超时时间研究过一个小技巧就是time>模拟用户组数量*1000/user thread number/loop count 可以避免因为设置 timeout =0 时，出现一直等待模拟用户组数量卡死现象情况
3.关于插件: tps trt, activate thread ,监控汇总以及图形插件下载地址:Extras.jar
https://github.com/chen1932390299/JavaProject/raw/JmeterJavaBranch/lib_jtlChange/ext/JMeterPlugins-Extras.jar
4.数据分析:对于压力测试很多人直接都不考虑持续压力测试的这种情况，以较短时间的一段数据来衡量整个服务性能数据是很不科学的:
首先什么是虚拟用户数，什么是并发量，甚至有些pm在表达自己或者用户需求时都没搞清并发和用户数的具体区别，jmeter用户模拟是通过线程实现，一个线程代表着一个虚拟用户；很多新手一上来就是线程数等于并发数堆上去，就是干更有甚者直接拿着一台windows
模拟出5000,甚至更高的数据并发，被很多经验丰富的技术人员所诟病能达到效果么，或许有人会讲了并发本就没有真正意义的并发的确我们并发不可能一点点时间都不差，我们终不过是实现一个更接近并发场景的场景构造就和我们极限求导一个思想，无限逼近那个理想效果；广义并发我们称为同一时时刻发生的所有用户行为，可以做不同的事，也可以做相同的事；狭义来讲，我们认为同一时间做相同的事；那么有没有想过为什么不能这样做呢，首先线程启动是又先后顺序的其次压力机器的资源是有限的当达到上限会对线程排队；其次，单台机器内存有限不可能无限制启动5000甚至上万线程，想要实现更高的并发需要以来分布式压测来解决资源问题分摊请求压力一台master可以对应多太slave 执行机器
计算公式:
concurrent = requests_totals*avgtime_rep/time_totals_continue
request_totals约等于 tps*time_totals_continue
也有一些网友采用tps*avgtime/1000方式这样有一个风险就是如果你娶到的波动的一个峰值获取波谷，这就意味着你的所有请求都的为你的这个tps值买单这是很有风险的
整个推导过程以一段时间的数据请求总时间/持续压测时间来衡量这段时间的服务器实际并发量，通过计算来得到服务器在不同用户并发下实际能达到的并发处理值也就是每秒处理的实际请求数作为实际并发值，因此我们也可以通过反向计推算出我们想达到某一并发所需要的虚拟用户数,也就是userthreads数量；
vuser concurrent total_requests avg_time_rep tps load_total_times
"10" "8.436" "13490" "37" "228.2" "60sec"
"71" "49.5895" "14342" "281" "245.3" "60sec"
"190" "90.662" "9692" " 572" "158" "60sec"
但是这个只是一个大概值，其次随着并发数量增加本地资源耗费以及服务负载增加 user threads 与 并发concurrent 转换率会由1:1 随着thread数量增加，转换率会越来愈低，而在linux会由于io,内存，cpu综合性能优于windows转换率能到达1:1.随着并发增加也能依旧保持1:0.8的优秀转换率，这些都是我和同事一起在工作过程中经过压力统计观测发现的一些有趣的事情:
activate thread 监控:
transcations thrououtput/threads监控 :
rtt监控:
transcations persecond 监控数据:
聚合报告:
标签：abr 求导 activate 获取 新手 out jmeter 研究 nbsp
原文地址：https://www.cnblogs.com/SunshineKimi/p/11359647.html
