服务器命中/秒超过活动线程数？ | JMeter的

Question

我正在运行负载测试，通过JMeter发出HTTP请求来测试服务器的吞吐量。

我使用Thread Stepper插件，允许我增加用于在特定时间段之后发出请求的线程数。

下图显示了有效时间的活动线程数，另一个显示了我能够进行的每秒相应命中数。 第三个图显示了请求的延迟。第四个显示每秒的响应。

我无法将这四张图组合在一起。

在服务器每秒点击次数中，我只能使用50个活动线程，每秒最多可以发出大约240个请求。但是，请求的延迟大约是1秒。

我的理解是单个线程会发出请求，然后在发出第二个请求之前等待响应返回。 由于在我的情况下最小延迟大约是1秒，JMeter如何只用50个线程就能达到每秒240个请求？

服务器每秒点击次数，最多240次，只有50个线程。怎么样？ 响应延迟（最小延迟为1秒）

有效时间的活动线程（当服务器命中时为50个线程为240 /秒）

每秒响应次数（最多300次/秒，怎么样？）

Answer 1

我的期望是原因可能在：

1. 响应时间小于1秒，因此JMeter能够每秒发送多个请求每个线程

2. 根据HTTP redirections，它可能还与Embedded Resources和/或plugin's documentation处理相关联：

     

   Hits从交易和嵌入资源点击中删除子样本。

   例如，具有1个单用户的单个HTTP请求导致20个子样本，这些子样本由“每秒服务器命中数”插件计数。

   

Answer 2

我花了一些时间分析您提供的四个图，并且合理地绘制了Jmeter图（由于您感觉到Jmeter绘制不正确，所以我将尝试解释为什么这些图看起来对我来说正常）似乎很有意义。从@Dmitri T提供的答案的第一点中得出线索，我开始进行以下分析：

1。就像@Dimitry T指出的那样，响应的数量比发送到服务器的命中（请求）数量更快。当第一批匹配在0到前五分钟之间的50到70之间发送时，可以从“响应数/秒”图表中看到。对于这组请求的响应速度要快得多，即从0到前五分钟的响应速度是60到90。.从5到10分钟触发的命中结果观察到相同的趋势（响应比请求快（命中），即100到150个响应，而85到130个命中。）...因此，连续生成负载生成器能够发送更多命中，更多命中和50个活动线程更多命中...这将向上正斜率加上Thread Stepper插件的功能。

因此，命中和响应图呈锁定步进模式（一致行进），与每秒命中图相比，响应图具有更好的斜率。

这种向上的快乐趋势一直持续到23分钟，由于整个处理能力的使用导致排队效应。在这个时间点上，所有图表似乎都与它们到目前为止所做的事情相反，即持续了22.59分钟。 响应等待时间（即，从23分钟开始增加获取响应的时间。与此同时，每秒点击数下降（可能是由于没有足够的线程可用于加载生成器或触发下一个请求，因为它们aka用户）处于队列中，并且尚未退出发出下一个请求的流程。从响应数图表中可以看出，请求的下降降低了接收响应的速度。但是您仍然可以看到“服务中心”仍在处理中请求有效，即回传请求的到达速度更快，即根据排队论，服务速度比到达速度更快，因此是我们分析的重点1。

在60个用户负载下，发生了某事..发生了队列！（通过同时检查响应时间图的下降和吞吐量图下降来确认这一点。如果是，则将请求通过管道传递到服务器上，即排队。）这就是所有服务中心都忙碌的时刻。因此，响应时间的缩短会影响用户线程，因为它们无法生成新的匹配，从而导致每秒的匹配减少。

从每秒响应数观察到的错误代码，即400,403,500和504，似乎是响应代码的一部分，从第10个用户负载开始，这可能表示时间限制或数据问题（csv的前10个用户）在数据库中有适当的数据，其余则没有）。

或者它可能与“信贷”或“借方”交易一起使用，因为两者都可能发生冲突……或在银行帐户上陷入僵局等。

如果您注意到所有错误代码的性质，则可以看到它们在很多情况下会收到更多的响应，即直到23分钟为止，并且由于由于从第23分钟开始排队而导致的响应水平降低，因此减少了响应的数量因此与响应代码成正比。 504（网关超时）错误是处理大量时间的肯定信号，并且Web服务器超时意味着负载很高。因此，我们可以认为直到40分钟时80个用户才是合理的负载。系统的负载能力（很明显，如果观察到更多的504错误，我们可以将该点固定为系统可以承受的无压力负载。）

***重要提示：检查您的每秒HITS图形配置：另一个观察结果是，用于绘制图形的计量参数可能与预期的比例尺（即每秒）不同步。您根据配置进行绘制的每秒点击数图表可能为500毫秒（即半秒）。因此，这可能会导致绘图上升，即高于每50个用户50次点击。.