本文基于分布式跟踪系统(Jaeger)实现了一种新的performance profiling，把trace分成四层进行分析。

一方面，性能分析主要是单机+平均值，没法处理分布式和tail latency的情况；另一方面，分布式追踪是一条一条的，很难处理。论文的核心论点是：用分布式+aggregation解决上面的问题。

tprof将trace按照四个维度分层

在顶层，所有的trace被汇总到一起，并提供整体的统计数据（平均延迟、尾部延迟等）
在第二层，trace是按请求类型组织的。例如，向社交网络发布新消息的post将与read post的请求分开
在第三层，根据trace结构或者使用的服务/操作进行划分。例如，有cache miss并查询数据库的trace将与有cache hit的trace分开
在第四层，trace分组的依据是每个span都有相同的子span，且顺序一致。
- 定义subspans是span一定在干些什么的时间啊（图4很清楚了）

tprof

Layers 1/2: Operation analysis

第一层：所有可用的trace被分组，形成一个代表系统整体行为的组。这使我们能够像现有的粗粒度性能分析器一样分析系统。

第二层：追踪是根据请求类型来分组的。默认情况下，tprof使用跟踪中的根跨度（通常是一个API端点）来分组，但请求类型的识别可以由用户定义（例如，基于一个属性）。

tprof计算每个操作的延迟平均值、标准偏差和第50/99个百分位数以及总体延迟，还有纯运行时间，也就是减去子span的时间。 the operation durations excluding time periods where one or more of the operation’s child spans is running

Layer 3: Span and child analysis

具有相同的span和相同的父/子关系的trace被分成一组。但是只考虑结构，不考虑顺序。

tprof以span的角度计算aggregation和child diff。 child diff指的是span start、子span、span end之间的时间差。

Layer 4: Subspan analysis

在第四层中，我们在分组过程中同时考虑了trace的结构和跨度的顺序。

tprof定义了一个新的概念叫subspans。比如图4中。 Group 1好理解，就是A在B和C都没有运行的时候肯定在跑些什么，那就是subspans。 Group 2的A1是因为他调用了C，所以A1这段肯定也在跑些什么。

Aggregate trace visualization

subspan分析的一个主要好处是能够根据average span和subspans duration合成一个 "总体 "跟踪。

Theorem 1：如果不用平均值计算，可能会计算出非法的一个结果。论文中例子给的是如果不用平均值，用的是99th，就overlap了。显然。

Tail latency support

tprof根据用户定义的阈值（例如90%），将该组进一步细分为"正常"trace和"尾部"trace。超过阈值百分数的最慢的请求被标记为尾部请求，其余的被标记为正常请求。

Automated performance diagnosis

为了帮助用户进行性能诊断，tprof分析了汇总的统计数据，并自动生成了一份报告。

在第一层，tprof识别出所有可用trace中最慢的操作。

在第二层中，tprof缩小到第一层中看到的速度减慢影响最大的请求类型。此外，tprof通过比较尾部和正常trace，对减速是否是尾部特有的进行分类。比率超过了一个阈值，tprof就将其标记为尾部问题。阈值默认为4倍。

由于一个操作可能在一个trace中的多个span中被使用（例如对数据库的多次调用），tprof使用第3层的数据来缩小具体的问题span以及span中的缓慢区域。

最后，tprof分析了第4层的数据，以确定哪个第4层组最能表现出有问题的subspan。通过计算和排序，找出经常出现且占其span很大一部分的缓慢subspan。