通过在全连接图上迭代，得到多服务间因果分析。
background
几个use case
- 关键路径分析
- slack分析
- 异常检测
End-to-end request tracing
- 规定不同的request至少需要包含五个部分
- unique request identifier
- executing computer
- local timestamp
- event name (比如start of DOM rendering)
- task name, task is defined to be a distributed thread of control
- 时钟偏差
- client_send->server_receive->server_send->client_receive, client的时间减去server的时间, 除以一半
- 为了校正可能存在的波动，it makes separate RTT and clock skew calculations for each pair in the cross-product of requests
- TCP slow starts
- 为了保证概率相同，trace都是one-sample的
The Mystery Machine
定义三种因果关系
- Happens-before
- Mutual exclusion
- Pipeline
一开始假设是全连接的，然后不停迭代，如果有counter-example的话就把对应的边去掉
Results
Case 1
对端到端性能进行了测量。
- 关键路径分析的重要性：能看到整体的相对关系，而不是单一组件
- 关键路径上的高差异：关键路径在不同的请求中发生了巨大的变化，每个部分中的任何一个都可能主导延迟
- 按连接类型分层：Facebook的边缘负载平衡系统给每个传入的请求打上网络类型的标签，不同的连接情况是不一样的
- 按客户平台进行分层：不同的平台也是不一样的
- 按浏览器进行分层：同
- 按测量的网络带宽进行分层：同
Case 2
对潜在的性能优化--差异化服务--进行早期探索。 我们使用The Mystery Machine来直接测量我们的跟踪数据集中可用的服务器处理时间的松弛程度。
也就是因为slack的存在，有些事情可以不急着做。
- 验证松弛估计：用数据集做的实验
- 预测Slack：回忆一个特定的用户在先前连接到Face-book时经历的松弛
- 潜在的影响：把slack作为最后期限