JMeter 机器版本：2.13 r13365067、2.11.20140918 | Java：OpenJDK 1.7.0_79 | 操作系统：Debian 8.1
我遇到了一个问题，即某些 HTTP 请求似乎在负载注入器上处理的时间过长，而负载注入器并没有真正处于负载之下。
来自具有 20 个 vU（具有缓存，在较弱的负载注入器上，JMeter v2.11）和 40 个 vU（没有缓存，在更高规格的负载注入器上，JMeter v2.13）的测试结果文件的示例：
<time_stamp>,3257,<request_name>,200,<thread_name>,true,28537,20,20,437
<time_stamp>,5158,<request_name>,304,<thread_name>,true,138,40,40,0
在第一种情况下，内存为 75%，在第二种情况下低于 50%。CPU 似乎没有出现峰值（以 1 秒为间隔测量），并且在两个示例中最高达到 20%。检查了 JVM 的垃圾收集，在请求时似乎 GC 也没有达到极限（实际上在测试期间没有任何时候）。
在启用缓存（通过缓存管理器并选中“使用缓存控制/过期标头...”）的情况下，我注意到了这一点，并且像上面的第二个示例一样，得到了 5158 毫秒的不切实际的响应时间。
这只发生在迭代期间的某些步骤和多个线程，但不是全部。
似乎 JMeter 以某种方式处理结果的时间过长，但我真的看不出我的负载注入器负载很重，导致处理时间为几秒钟。
显然，这弄乱了性能统计数据，所以我想知道这是怎么发生的。
希望有人可以提供帮助。
编辑：@First 示例：ResponseTime >> Latecy > 0 的情况发生在两台 JMeter 机器（JMeter v2.11、JMeter v2.13）上。
@第二个示例：ResponseTime >> Latecy = 0 的情况仅发生在使用 JMeter v2.13 的机器上。
第二次编辑：事实证明，我运行什么 JMeter 版本（或在哪个节点上）并不重要。
正则表达式我的结果文件：对于相同的请求资源，缓存（延迟 = 0），带有标头检查，大约 10% 需要 1 秒或多秒。如果没有标题检查，它是 6%。