Testing JMeter聚合报告出现故障

有人遇到错误的报告吗？在本教程之后，我设置了一个web测试计划，只是添加了一个CSV数据集配置来从文件中读取请求参数。测试过程在没有警告的情况下完成，但Aggreate报告中的数据很奇怪

它给出了如下内容：

但根据文件,

这意味着

平均*吞吐量

几乎应该是

1000

我的报告怎么了

---

ps：上面的公式来自

我们从头开始：如果您运行一个线程，一次迭代，并且采样器在1001毫秒内完成，那么您的吞吐量将是1000毫秒/1001毫秒=1秒

现在假设您再添加一个线程，它们都立即开始（仍在运行1次迭代）。比如说，平均值保持不变。因此，吞吐量将为2*（1000 ms/1001 ms）=2/秒（换句话说：2台采样器在1秒内完成）

现在，让我们添加迭代：2个线程，2个迭代，相同的平均值：在第一秒，吞吐量将与之前的2/s相同，在第二秒，吞吐量将与之前的2/s相同，因此平均仍为2/s左右

但是现在让我们添加一个1秒的上升周期：第一个线程立即开始，而第二个线程在500毫秒后开始；同样的平均数。因此，第一秒的吞吐量将是1/秒（第二个线程还没有完成第一次迭代，因为它是在稍后开始的）；第二秒吞吐量为2/秒（第一个线程第二次迭代，第二个线程第一次迭代）；在第三秒，线程1完成，但第二次仍然在第二次迭代的中间，所以吞吐量将是1秒。因此，平均吞吐量=（1/秒+2/秒+1/秒）/3秒4/3秒=1.3/秒

诸如此类——在达到饱和点之前相当无聊。在饱和点之前，您给服务器的越多，吞吐量就越好/越大。在饱和点之后，即使服务器有更多的工作，也无法提高吞吐量

例如，假设我一次只能向服务器发送一个请求。因此，即使我有2个线程，在上面的示例中，吞吐量仍然是1/秒

因此，您的屏幕截图显示4000个样本，平均229毫秒，吞吐量为56.8/秒。如果有一个用户按顺序运行4000次迭代，则吞吐量为1000/229 ms=4.4/sec，因此有多个用户；56.8/sec吞吐量实际上意味着大约16个用户。我不知道到底有多少，因为我不知道你们的加速时间，也不知道你们是在饱和点之前还是之后。例如，您可能有100个并发用户，但实际上只有大约16个并发连接建立到服务器（超过饱和点），或者您已经进行了缓慢的升级，这意味着用户17启动时，用户1已经完成。所以，即使服务器可以处理更多的数据，它也永远不会有机会

哦，它也可以少于16个并发用户：我是从平均吞吐量来判断的，这在大多数情况下是一个很好的指标，但并不总是这样：它可能会在某个时间段受到特别高或低的吞吐量的影响。例如，最初吞吐量是1/秒，然后当服务器启动时，它变成了100/秒。平均值是50/秒，但最后一个数字-50/秒是没有意义的。更重要的是，看看价值是如何随时间变化的

---

希望这个解释有帮助

我不认为这是一个有明确答案的问题，该文件忽略了他们如何计算这些数字以及我们如何验证这些数字的大部分细节。我认为在没有任何解释的情况下否决别人的问题是不合适的。谢谢你的解释，我不理解你的观点。我将threadnum设置为20，ramp up Period设置为0（我希望同时发送20个请求），迭代200次。我测试的应用程序中的逻辑无法以并发或并行方式处理请求，因此我认为一个用户和16个用户的吞吐量应该完全相同。我想测试将逻辑更改为并发后qps将如何更改。

Throughput = (number of requests) / (total time in secs)
           = 1000 * (number of requests) / (total time in millionsec)
Average = (total time in millionsec) / (number of requests)