摘要：作者唐劉很早之前就看過(guò)大神的一篇文章，里面提到了性能測(cè)試工具的問(wèn)題，但當(dāng)時(shí)并沒(méi)有怎么在意。這幾天有人在我們自己的性能測(cè)試工具上面問(wèn)了這個(gè)問(wèn)題，我才陡然發(fā)現(xiàn)，原來(lái)我們也有。原文性能測(cè)試工具的問(wèn)題

?

作者：唐劉

很早之前就看過(guò) Gil 大神的一篇文章《Your Load Generator Is Probably Lying To You - Take The Red Pill And Find Out Why》，里面提到了性能測(cè)試工具 coordinated omission 的問(wèn)題，但當(dāng)時(shí)并沒(méi)有怎么在意。這幾天有人在我們自己的性能測(cè)試工具 go-ycsb （https://github.com/pingcap/go-ycsb/issues/26）上面問(wèn)了這個(gè)問(wèn)題，我才陡然發(fā)現(xiàn)，原來(lái)我們也有。

首先來(lái)說(shuō)說(shuō)什么是 coordinated omission。對(duì)于絕大多數(shù) benchmark 工具來(lái)說(shuō)，通常都是這樣的模型——啟動(dòng)多個(gè)線程，每個(gè)線程依次的發(fā)送 request，接受 response，然后繼續(xù)下一次的發(fā)送。我們記錄的 latency 通常就是 response time - request time。這個(gè)看起來(lái)很 make sense，但實(shí)際是有問(wèn)題的。

一個(gè)簡(jiǎn)單的例子，當(dāng)我們?nèi)?KFC 買炸雞，然后我們排在了一個(gè)隊(duì)伍后面，前面有 3 個(gè)人，開始 2 個(gè)人都好快，30 秒搞定，然后第三個(gè)墨跡了半天，花了 5 分鐘，然后到我了，30 秒搞定。對(duì)于我來(lái)說(shuō)，我絕對(duì)不會(huì)認(rèn)為我的 latency 是 30 秒，而是會(huì)算上排隊(duì)的時(shí)間 2 x 30 + 300，加上服務(wù)時(shí)間 30 秒，所以我的總的時(shí)間耗時(shí)是 390 秒。這里不知道大家看到了區(qū)別了沒(méi)有，就是市面上大多數(shù)的性能測(cè)試工具，其實(shí)用的是服務(wù)時(shí)間，但并沒(méi)有算上等待時(shí)間。

再來(lái)看一個(gè)例子，假設(shè)我們需要性能測(cè)試工具按照 10 ops/sec 的頻繁發(fā)送請(qǐng)求，也就是希望每 100 ms 發(fā)送一個(gè)。前面 9 個(gè)請(qǐng)求，每個(gè)都是 50 us 就返回了，但第 10 個(gè)請(qǐng)求持續(xù)了 1 s，而后面的又是 50 us。可以明顯地看到，在 1 s 那里，系統(tǒng)出現(xiàn)了卡頓，但這時(shí)候其實(shí)只有 1 個(gè)請(qǐng)求發(fā)上去，并沒(méi)有很好地對(duì)系統(tǒng)進(jìn)行測(cè)試。

對(duì)于第一個(gè)排隊(duì)的例子，為了更好的計(jì)算 latency，YCSB 引入了一個(gè) intended time 的概念，即記錄下操作實(shí)際的排隊(duì)時(shí)間。它使用了一個(gè) local thread 變量，在 throttle 的時(shí)候，記錄：

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);
    }
}

然后每次操作的時(shí)候，使用 intended time 計(jì)算排隊(duì)時(shí)間：

public Status read(String table, String key, Set fields,
                 Map 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 才有作用。

我當(dāng)初在看 YCSB 代碼的時(shí)候，一直沒(méi)搞明白為什么會(huì)有兩種時(shí)間，而且也不知道 intended time 到底是什么，后來(lái)重新回顧了 coordinated omission 才清楚。也就是說(shuō) YCSB 通過(guò) intended time 來(lái)計(jì)算排隊(duì)時(shí)間。

但 YCSB 還是沒(méi)解決上面說(shuō)的第二個(gè)問(wèn)題，如果系統(tǒng)真的出現(xiàn)了卡主，測(cè)試客戶端仍然會(huì)跟著卡主，因?yàn)槭峭桨l(fā)送請(qǐng)求的。在網(wǎng)上搜索了一下，看到了一篇 Paper《Coordinated Omission in NoSQL Database Benchmarking》，里面提到了將同步改成異步的方式，也就是說(shuō)，每次的任務(wù)是一個(gè) Future，首先根據(jù) target 按照頻率發(fā) Future 就行，至于這個(gè) Future 什么時(shí)候完成，后面再說(shuō)。而且因?yàn)槭钱惒降?，所以并不?huì)卡主后面的請(qǐng)求。

那么具體到 go-ycsb，我們?nèi)绾谓鉀Q這個(gè)問(wèn)題呢？我現(xiàn)在唯一能想到的就是利用 Go 的 goroutine，按照一定的頻率去生成 goroutine，執(zhí)行測(cè)試。當(dāng)然 Go 自身也會(huì)有調(diào)度的開銷，這里也需要排除。如果要測(cè)試的服務(wù)出現(xiàn)了卡頓，就會(huì)導(dǎo)致大量的 goroutine 沒(méi)法釋放，最終 OOM。雖然這樣子看起來(lái)比較殘暴，但這才是符合預(yù)期的。

這個(gè)只是一個(gè)想法，具體還沒(méi)做。一個(gè)原因是不同于其他語(yǔ)言，Go 的 goroutine 其實(shí)天生就能開很多，所以通常我都是上千并發(fā)進(jìn)行測(cè)試的，假設(shè)我們有 1000 個(gè)并發(fā)，按照 1 ms 一次的頻率，其實(shí)也就等同于每個(gè) goroutine 依次發(fā)送了。當(dāng)然，有總比沒(méi)有好，如果你對(duì)這塊感興趣，歡迎給我們提交 PR，或者給我發(fā)郵件詳細(xì)討論 tl@pingcap.com。

原文：性能測(cè)試工具的 Coordinated Omission 問(wèn)題