很早之前就看过 Gil 大神的一篇文章《Your Load Generator Is Probably Lying To You - Take The Red Pill And Find Out Why》，里面提到了性能测试工具 coordinated omission 的问题，但当时并没有怎么在意。这几天有人在我们自己的性能测试工具 go-ycsb 上面问了这个问题，我才陡然发现，原来我们也有。

什么是 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，而QQ靓号后面的又是 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 计算排队时间：

public Status read(String table, String key, Set fields,

             Map<String, ByteIterator> result) {

try (final TraceScope span = tracer.newScope(scopeStringRead)) {
long ist = measurements.getIntendedtartTimeNs();
long st = System.nanoTime();

    Status res = db.read(table, key, fields, result);

long en = System.nanoTime();

    measure("READ", res, ist, st, en);
    measurements.reportStatus("READ", res);

return res;

}

}
需要注意，只有 YCSB 开启了 target，intended time 才有作用。

我当初在看 YCSB 代码的时候，一直没搞明白为什么会有两种时间，而且也不知道 intended time 到底是什么，后来重新回顾了 coordinated omission 才清楚。也就是说 YCSB 通过 intended time 来计算排队时间。

但 YCSB 还是没解决上面说的第二个问题，如果系统真的出现了卡主，测试客户端仍然会跟着卡主，因为是同步发送请求的。在网上搜索了一下，看到了一篇 Paper《Coordinated Omission in NoSQL Database Benchmarking》，里面提到了将同步改成异步的方式，也就是说，每次的任务是一个 Future，首先根据 target 按照频率发 Future 就行，至于这个 Future 什么时候完成，后面再说。而且因为是异步的，所以并不会卡主后面的请求。

Go YCSB
那么具体到 go-ycsb，我们如何解决这个问题呢？我现在唯一能想到的就是利用 Go 的 goroutine，按照一定的频率去生成 goroutine，执行测试。当然 Go 自身也会有调度的开销，这里也需要排除。如果要测试的服务出现了卡顿，就会导致大量的 goroutine 没法释放，最终 OOM。虽然这样子看起来比较残暴，但这才是符合预期的。

这个只是一个想法，具体还没做。一个原因是不同于其他语言，Go 的 goroutine 其实天生就能开很多，所以通常我都是上千并发进行测试的，假设我们有 1000 个并发，按照 1 ms 一次的频率，其实也就等同于每个 goroutine 依次发送了。