【发布时间】：2015-10-28 14:41:56
【问题描述】：
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 以某种方式处理结果的时间过长，但我看不出我的负载注入器负载过重，导致处理时间为几秒。
很明显，这弄乱了性能统计数据，所以我想知道这是怎么回事。
希望有人能提供帮助。
编辑： @第一个示例：ResponseTime >> Latecy > 0 的情况发生在两台 JMeter 机器（JMeter v2.11、JMeter v2.13）上。
@Second 示例：ResponseTime >> Latecy = 0 的情况仅在装有 JMeter v2.13 的机器上发生。
第二次编辑： 事实证明，我运行什么 JMeter 版本（或在哪个节点上）并不重要。
正则表达式对我的结果文件进行了处理： 在相同请求的资源中，缓存（延迟=0），带有标头检查，大约 10% 需要 1 秒或多秒。如果没有标题检查，则为 6%。
【问题讨论】：
标签： caching jmeter response-time