性能测试工具的 Coordinated Omission 问题
Posted PingCAP
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了性能测试工具的 Coordinated Omission 问题相关的知识,希望对你有一定的参考价值。
很早之前就看过 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,或者给我发邮件详细讨论 tl@pingcap.com。
以上是关于性能测试工具的 Coordinated Omission 问题的主要内容,如果未能解决你的问题,请参考以下文章