什么是协调的预兆，如何恰当地避免它？

Question

最近，当我发现wrk的延迟结果看起来不正常时，我遇到了所谓的“协调遗漏”的问题。

一些搜索让我找到了如何不衡量延迟和你的负荷发生器可能在骗你--拿着红丸，找出原因，吉尔·泰恩(氏)邮件

认为闭环负载发生器不能反映真实世界的论点是有道理的。但wrk和wrk 2的S策略都不能使我信服，他们使用固定的最大联系限制，用一种类似加权平均([医]wrk法)的数学方法对CO进行补偿。我找不到任何确凿和正式的证据证明这种方法是正确的。

我还发现了一些关于其他基准测试工具的讨论。正如K6论坛的讨论所指出的，K6有几个执行模型来解决这个问题。和提供了一些建议.。

既然协调遗漏问题已经引起了基准工具界的关注，我真的很想知道是否对此进行了认真的研究，有什么正确的方法来避免它，以及wrk和wrk 2‘S的策略正确吗？

Answer 1

假设您有一个简单的测试，它在循环中运行10个请求。

• 9个请求响应时间为1秒。
• 第10次请求以任何理由花费10秒。

总测试持续时间为20秒，平均响应时间为1.9秒，吞吐量为每秒0.5次请求。

在我看来，忽视或掩盖这一“长”请求是非常糟糕的做法，因为这种行为必须有正当的理由。

在JMeter的世界中，我只能想到由于JVM垃圾收集 (这是不可避免的)可能的“不可靠”结果，但是它可以通过以下方法来解决：

• 在JMeter中运行分布式模式，因此如果一个负载生成器卡住了，其他的将仍然工作
• 如果当前线程数量不足以通过吞吐量成形定时器和并发线程组组合达到/保持目标吞吐量，则有一个备用的C14来交付额外的负载

wrk和k6没有分布式执行模式，这就是为什么他们必须通过对响应数据的人为操作来解决这个问题的原因。