性能测试工具的 Coordinated Omission 问题

Posted 2021-04-29 PingCAP

很早之前就看过 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 的时候，记录：

然后每次操作的时候，使用 intended time 计算排队时间：

需要注意，只有 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 依次发送了。当然，有总比没有好，如果你对这块感兴趣，欢迎给我们提交 PR，或者给我发邮件详细讨论 [e-mail]。