我已经开始使用 jmeter 进行分布式性能测试。如果我给出方案 1：
no.of threads: 10
ramp up period: 1
loop count: 300
一切运行顺利，因为场景 1 在 300 秒内转换为 3000 个请求。即每秒 10 个请求。
如果我给出方案 2：
no.of threads: 100
ramp up period: 10
loop count: 30
Afaik，场景 2 也在 300 秒内执行 3000 个请求，即每秒 10 个请求。
但是事情开始失败，即服务器面临繁重的负载并且请求失败。理论上，scenario1和scenario2应该是一样的，对吧？我错过了什么吗？
所有这些都是繁重的调用，在正常负载下每个都需要 1-2 秒。
【问题讨论】：
标签： jmeter performance-testing load-testing
我们将非常清楚 Rampup 时间 以下是官方文档的摘录
场景 1： 线程数：10 加速期：1 循环次数：300
在上述场景中，需要在 1 秒内创建 10 个线程（虚拟用户）。每个用户将循环 300 次。因此，服务器将收到 3000 个请求。 Throughput 以上配置无法提前计算。它根据服务器能力、网络等而波动。您可以使用some components 和plugins 控制吞吐量。
场景 2：线程数：100 加速期：10 循环次数：30
在场景 2 中，10 秒内创建了 100 个线程（虚拟用户）。 100 个虚拟用户将同时向服务器发送请求。每个用户将发送 30 个请求。在第二种情况下，与场景 1 相比，您将拥有更高的吞吐量（每秒的请求数）。看起来服务器无法处理同时发送请求的 100 个用户。
加速时间适用于每个线程的第一个周期。它将模拟每个用户在第一次迭代中的第一次请求之间的延迟。
【讨论】：
在场景 2 的理想世界中，您每秒将有 100 个请求，测试将在 30 秒内完成。
在第二种情况下，您具有相同的执行时间这一事实表明您的应用程序处理传入请求的速度不能超过每秒 10 个。
尝试增加第二种情况的启动时间并查看以下图表：
通常，当您增加负载时，“每秒事务数”应增加相同的因子，“响应时间”应保持不变。一旦响应时间开始增长并且每秒事务数开始减少，这意味着您通过了saturation point 并发现了瓶颈。您应该报告最大性能点并调查第一个bottleneck的原因
更多信息：What is the Relationship Between Users and Hits Per Second?
【讨论】：
在场景 2 中，10 秒后您有 100 个 concurrent users 并行执行请求，您的服务器可能无法很好地处理或阻止此类负载
并发用户负载测试会同时向 Web 应用程序发送人工流量，以对基础架构施加压力并记录持续重负载。
在 10 秒后的场景 1 中，您有 10 个并发用户在流中循环，而不会导致服务器负载
请注意，您的服务器可能会限制仅针对特定请求提出请求的用户数量
【讨论】：