很早之前就看过 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，而后面的又是 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<String> 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 啥时候完成，后面再说。而且因为是异步的，所以并不会卡主后面的请求。因为这个代码是 Scala 的，我看 Java 已经够吃力了，所以也就懒得深入了。
Go YCSB
那么具体到 go-ycsb，我们如何解决这个问题呢？我现在唯一能想到的就是利用 Go 的 goroutine，按照一定的频率去生成 goroutine，执行测试。当然 Go 自身也会有调度的开销，这里也需要排除。如果要测试的服务出现了卡顿，就会导致大量的 Goroutine 没法释放，最终 OOM。虽然这样子看起来比较残暴，但这才是符合预期的。
这个只是一个想法，具体还没做，一个原因就是懒，另一个原因是不同于其他语言，Go 的 goroutine 其实天生就能开很多，所以通常我都是上千并发进行测试的，假设我们有 1000 个并发，按照 1 ms 一次的频率，其实也就等同于每个 Goroutine 依次发送了。当然，有总比没有好，如果你对这块感兴趣，欢迎给我们提交 PR，或者给我发邮件详细讨论 tl@pingcap.com。
