[TOC]
Little’s Law
解决的目标问题
排队论
定义
系统在稳定的状态下有
$L=λW$
其中，$L$是系统内个体的平均数量，$λ$是个体到达平均速率，$W$是个体在系统中的平均停留时间。
推论
$1- 在稳定状态下的生产系统中，系统内部的平均在制品库存数$WIP$，等于系统的平均输出$TH$，乘以每个产品在系统内的平均周期时间$CT$，即$WIP = TH · CT$
$2- Utilization Law 使用率的计算$U=X∗St$，即使用率 = 吞吐率 * 服务处理时间
应用场景
单一的系统部件：磁盘，CPU
多个子系统组成的复杂系统：网页界面相应时间
管理学
系统测试、软件性能分析：确保观察到的性能结果瓶颈是不是由测试设备造成的
制造业：根据生产率和在制品数量来预测交货时间
人员配置
Tail Latency
即尾延迟。延迟有三种：low latency、middle latency、tail latency
定义
长尾请求一般是指明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准， 也就是99%的请求延迟要满足在一定耗时以内， 1%的请求会大于这个耗时， 而这1%就可以认为是长尾请求。
开发和运维高并发系统的工程师可能都有过类似经验，明明系统已经调优完毕，该异步的异步，该减少互斥的地方引入无锁，该减少IO的地方更换引擎或者硬件，该调节内核的调节相应参数，然而，如果在系统中引入实时监控，总会有少量响应的延迟高于均值，我们把这些响应称为尾延迟（Tail Latency）。尾部延迟（也称为高百分比延迟）是指客户端很少看到的高延迟。例如：“我的服务通常在10毫秒左右响应，但有时需要100毫秒左右”。
产生的原因
系统/环境问题（磁盘老化）、超时、后台任务（GC）、超负荷运行、调度问题
对策
应对尾延迟的基本思想是hedging。最慢的实例决定我们的请求完成的时间。
- 发送比必要更多的请求，只收集最快的返回，有助于减少尾部。Send 2 instread of 1. Send 11 instead of 10 (e.g. in erasure-coding 10 fragment reconstruct read). Send backup requests at 95% percentile latency.
- 金丝雀请求,，i.e. send normal requests but fallback to sending hedged requests if the canary did’t finish in reasonable time.
- 通常，较小的任务分区（微分区）将有助于实现更平滑的延迟分布百分位数。
- 减缓 head-of-line blocking. 少量开销较大的查询可能会增加大量并发开销较低的查询的延迟。Uniformly smaller tasks partitioning camn help.
- 处理超时
- 首先尝试a non-block try 读取（读取但不等待），然后进行尽力读取（读取并等待超时）。
- 当发现超时时，将相关资源标记为known slow。 并告知其他请求绕过这个资源。
- 要设置合适的超时值，我们可以设置为99.9% ，并动态调整它。 任意超时值可能有害。
- 更细粒度的调度，甚至是平衡延迟和成本的管理框架。(e.g. Bing’s Kwiken, also attached below.)
监控
有两种监控指标：
- Single operation
- Percentile statistics
监控应该能够：
- 提供可以从用户请求入口跟踪到硬件操作的trace id
- 涵盖每个级别的细分
- 覆盖容易出问题的地方
有几个方面需要监控：
- 与故障直接相关的错误，例如虚拟机停止/重新启动
- 直接影响用户体验的超时错误计数和自动限制
- Operation slowdown
- 典型的硬件性能，如CPU、网络、磁盘
- 提供从用户进入的跟踪、每个级别的细分以及最终到硬件的跟踪
参考
[2] Dean, Jeffrey, and Luiz André Barroso. “The tail at scale.” Communications of the ACM 56.2 (2013): 74-80.