完全没问题

脚本只能保证业务没问题。具体的场景要单独设计。比如并发场景，或者容量场景

还有不要同时艾特我跟几位社区大佬，我不配。。。

你这个 50/s 是每秒请求呀，不是服务处理能力。吞吐量控制器控制的是你的每秒的总响应数。
所以这里你有两个场景要考虑【50/s 是指的一个人 1s 内查询了 50 次还是很多人在 1s 内总共查询了 50 次请求】
如果是第一种，那这个 50 就是总 tps 呀，处理能力已经被你圈死了
如果是第二种，那你就要先计算平均并发数，然后再去测你的性能瓶颈

jmeter 能启动多少线程，由你的堆内存和栈内存决定

我圈了事物控制器在里面

这种怎么分析？

测试圈纪检委？

会

勾选永远，线程会以最大迭代次数去运行。最大迭代次数由请求的响应时间决定。响应时间如果是 10ms，那 1s 就可以迭代 100 次

如果你说的并发数指的是并发用户数，那么线程数就是并发用户数
如果你说的并发数是并发请求，那么它叫 rps，rps=（线程数 * 线程迭代次数）/s，称之为每秒并发请求数
不论并发用户数还是并发请求数，代表的都是压力值。压力测试通过设计压力值来测试服务器，获取 TPS 值，衡量服务端性能。
想加压力，要么加人，要么加单位请求。人做不到的只有机器来做

有疑惑的可以看一下我的博客https://testerhome.com/topics/21318

根据比例尺进行换算

熟人？你咋知道我名字的

负载不超过内核数，us+sy 的利用率在 50 到 80 之间。都算合理

看这个吧

你的字多，你有理

确实没有关联关系。只不过软缺页指标太高了，八成是有问题

@Lihuazhang @seveniruby @chenhengjie123

靠谱一点的结果，都是取 95% 响应时间

亲，取 95% 或者 90% 的响应时间哦

那是因为百度把你的出口 ip 给短暂封闭了

我没有引用 jar 包呀。只是本地起的 ide 去计算 sign，然后存到文件里面，让 jmeter 去读。jmeter 本身并没有引用任何 jar

jmeter 直接处理这些算法会影响性能，所以要分开