为什么要测量尾部延迟


如果不加以选择,您的服务响应时间可能会付出巨大的代价。 即使一小部分请求经历了极大的延迟,它也往往会影响您最有利可图的用户,而且效果不佳。

    最重要的是,长时间的响应时间会降低服务的恢复能力,使操作成本更高。但是,我走在自己前面——首先,让我们从定义什么是响应时间开始。

    您的服务响应请求所用的时间可能因几个因素而变化很大。网络超时、页面错误或重上下文切换的存在都会影响它。由于不是每个请求需要相同的时间,因此响应时间最好用分布来表示。通常,此分布是右倾斜和长尾。

image.png

    您可以使用平均值或算术平均值来汇总具有单个值的分布。但是,平均数是否具有代表性呢?虽然平均值有其使用,但如果您想知道用户经历特定响应时间的比例,则没有帮助。只需要一个疯狂的异常值来扭曲平均值。例如,如果 100 个用户使用单个请求访问您的服务,其中 99 个请求的响应时间为 1 秒,响应时间为 10 分钟,则平均值接近 7 秒。即使 99% 的用户体验响应时间为 1 秒,但平均响应时间是 7 倍!

    表示响应时间分布的更好方法使用百分位数。百分位数是响应时间百分比下降的值。例如,如果第 99 个百分位数为 1 秒,则 99% 的请求的响应时间低于 1 秒。响应时间分布的上百分位数(如第 99 个百分位数和 99.9 分位数)也称为尾部延迟。

image.png

    即使一小部分请求遇到这些极端延迟,它往往会影响您最有利可图的用户。这些用户往往是发出最高请求数的用户,因此出现尾部延迟的可能性更高。几项研究已经证明,高延迟会影响收入。负载时间仅延迟 100 毫秒,转化率就达 7%。

    为了避免丢失用户,您必须控制上百分位数响应时间。实现此目的的一个方法就是强制实施服务级别目标(SLO)。服务级别目标为给定指标设置目标可靠性级别。例如,您的 SLO 可以规定在一周的滚动时间窗口内 99% 的请求应在 1 秒内提供服务。如果您的服务在一周内收到 100 万个请求,则最多 10K 个请求可以超过 1 秒;如果服务在一周内收到 100 万个请求,则最多 10000 个请求可以超过 1 秒。这些 10K 请求也称为错误预算。

    事实证明,控制尾部延迟不仅让用户满意,而且显著提高了服务的恢复能力,同时降低了运营成本。为什么?因为,如果您被迫防范最坏情况下的响应时间,您碰巧也提高了平均情况。未选中的尾部延迟可以快速使服务陷入瘫痪。假设您的服务使用 2K 线程来为 10K 请求/秒提供服务。根据小定律,线程的平均响应时间是200ms。突然,网络交换机变得拥塞,碰巧有 1% 的请求从该交换机后面的节点提供。1% 的请求(10K 中/秒的 100 个请求)开始需要 20 秒才能完成。


image.png

    您的服务需要多少个线程来处理响应时间短的一小部分请求?好吧,如果每秒处理100个请求需要20秒钟,那么就需要2K个额外的线程来处理缓慢的请求。因此,服务的线程数需要加倍以跟上负载!

    如果服务水平目标是基于尾部等待时间的,那么要保证这一点,您的服务就需要具有自我修复机制。别无选择。在我们之前的示例中,快速失败或在负载均衡器后面添加运行状况端点可能会成功。随着时间的流逝,这些机制减少的系统成本与运行系统的运营负担一样多。

    SLO应该有多严格?通常情况下,要使误差预算变得更加紧凑,从工程时间上讲是非常昂贵的,而采取这种做法没有多大意义,因为成本效益比太高而无法证明投资的合理性。

image.png

    最有效的方法取决于您的服务,但总的来说,任何高于3个9的值都很难实现,并且收益递减。


【总结】

    如果不加以控制,高延迟会影响您的收入和成本。 您无法解决无法衡量的问题-朝正确方向迈出的第一步是根据响应时间的百分位数实施SLO。 为了保证SLO,您将不得不建立自我修复机制来防范最坏情况下的尾部延迟。 作为一个很好的副作用,这些机制还将改善平均响应时间,并使您的服务的运营成本降低。


上一篇 下一篇

评论

登录后可发表评论


鹅鹅鹅鹅鹅鹅

张安冠:
10月01日 22:55
@1 哈哈哈哈哈哈哈

张安冠:
10月01日 22:55
得瑟得瑟

1:
09月29日 13:42
,,,,