摘要：作者唐刘很早之前就看过大神的一篇文章，里面提到了性能测试工具的问题，但当时并没有怎么在意。这几天有人在我们自己的性能测试工具上面问了这个问题，我才陡然发现，原来我们也有。原文性能测试工具的问题
作者：唐刘
很早之前就看过 Gil 大神的一篇文章《Your Load Generator Is Probably Lying To You - Take The Red Pill And Find Out Why》，里面提到了性能测试工具 coordinated omission 的问题，但当时并没有怎么在意。这几天有人在我们自己的性能测试工具 go-ycsb （https://github.com/pingcap/go-ycsb/issues/26）上面问了这个问题，我才陡然发现，原来我们也有。
什么是 coordinated omission首先来说说什么是 coordinated omission。对于绝大多数 benchmark 工具来说，通常都是这样的模型——启动多个线程，每个线程依次的发送 request，接受 response，然后继续下一次的发送。我们记录的 latency 通常就是 response time - request time。这个看起来很 make sense，但实际是有问题的。
一个简单的例子，当我们去 KFC 买炸鸡，然后我们排在了一个队伍后面，前面有 3 个人，开始 2 个人都好快，30 秒搞定，然后第三个墨迹了半天，花了 5 分钟，然后到我了，30 秒搞定。对于我来说，我绝对不会认为我的 latency 是 30 秒，而是会算上排队的时间 2 x 30 + 300，加上服务时间 30 秒，所以我的总的时间耗时是 390 秒。这里不知道大家看到了区别了没有，就是市面上大多数的性能测试工具，其实用的是服务时间，但并没有算上等待时间。
再来看一个例子，假设我们需要性能测试工具按照 10 ops/sec 的频繁发送请求，也就是希望每 100 ms 发送一个。前面 9 个请求，每个都是 50 us 就返回了，但第 10 个请求持续了 1 s，而后面的又是 50 us。可以明显地看到，在 1 s 那里，系统出现了卡顿，但这时候其实只有 1 个请求发上去，并没有很好地对系统进行测试。
YCSB对于第一个排队的例子，为了更好的计算 latency，YCSB 引入了一个 intended time 的概念，即记录下操作实际的排队时间。它使用了一个 local thread 变量，在 throttle 的时候，记录：
private void throttleNanos(long startTimeNanos) {
//throttle the operations
if (_targetOpsPerMs > 0)
{
// delay until next tick
long deadline = startTimeNanos + _opsdone*_targetOpsTickNs;
sleepUntil(deadline);
_measurements.setIntendedStartTimeNs(deadline);
}
}
然后每次操作的时候，使用 intended time 计算排队时间：
