How NOT to Measure Latency

https://www.infoq.com/presentations/latency-response-time/ https://bravenewgeek.com/everything-you-know-about-latency-is-wrong/ http://hdrhistogram.org/

如何正确地测量和解读延迟。里面有这么几个重点:

  1. 我们关注的不是单个延迟,而是延迟的分布。
  2. 95%, 99% pth反应不了真实情况,大部分用户会经历超过99%的延迟,取平均就更没有什么意义了。
  3. CO(coordinated omission) 协调一致的忽略,这个词不太好翻译。我们测量工具和方法,本身就让我们看到更好看的数据,而不是系统真实表现。
  4. 测量延迟的关键就在于,区分service time/response time. service time是你看到的系统服务时间,而response time是用户真实感受到的时间。

因为CO的原因,会让你的service time看起来非常非常的好,但是实际的response time是非常非常的差。作者给出了几个CO的例子,这些例子我们现实中经常遇到:第一个就是压力测试工具一旦发现系统不响应就会backoff, 其实这个时候系统本身已经出问题了,但是这段时间的延迟数据被忽略。最后系统表现好的时候我们测量次数多,而表现不好的时候测量次数少。第二个就是我们在代码里面增加timer.start()/stop(), 然后选择99%pth,而系统比如因为GC出现的pause时间就是1%,那么最后看到的数据都是没有GC pause时期的数据。

how-not-to-measure-latency-co0.png

how-not-to-measure-latency-co1.png


我们对下面一个测量延迟场景做分析。下面是正确的测试方法:

how-not-to-measure-latency-case0.png

但是如果我们在stalled期间只做了1次测量会怎么样呢(测试工具因为迟迟不返回所以挂住了):

how-not-to-measure-latency-case1.png

正确的测试方式应该如下,就是在stalled期间我们依然需要发起请求,如果我们期间不做任何请求话,那么就是CO

how-not-to-measure-latency-case2.png

how-not-to-measure-latency-case3.png

使用CO得到的错误延迟,不仅仅会让我们对系统有错误的理解,还会让我们认为某些改进是不好的。如果我们将stalled期间的延迟下降到了5ms,得到的数据反而比stalled的要更差。

how-not-to-measure-latency-case4.png

一切问题都是错误的测量方法导致的。


得到latency数值之后应该如何使用它呢?首先我们不能只使用99%, 至少也要99.99%或者干脆是max. 然后如果这个latency太高的话,通常意味着系统负载是过来的,没有办法处理过来,所以我们应该在系统指定的吞吐下进行压测。测量结果至少应该如下图:两个系统在不同的throughput下面,各自的99.9%, 99.99% latency有多少。如果我们选择99.99% latency作为参考,那么看这个latency是否可以接受。如果不能接受,那么就需要继续降低吞吐,知道符合latency条件为止。此时我们才能知道系统的正常负载是多少,然后在这个复杂下面比较各个系统的延迟,然后再进行容量规划。

how-not-to-measure-latency-comparison.png