NSDI11-Spectroscope-Diagnosing performance changes by comparing request flows

总结

• 比较两次执行（系统修改前后）的请求流（时间、结构体）发现问题；对时间方面，使用假设检验，检查某种分类的时间分布是否和之前一致，从而判断是否一致。对于结构，寻找变异及其对应的前体，来发现性能改变

• 设计的算法可以确定和排序请求流/时间中的改变

• 工具 Spectroscope

• 假设背景：我们的技术假设性能变化是由系统变化引起的(代码变化、配置变化等)。需要对比变化前后系统的执行来进行前体/编译的区分。

  • 可否应用于性能问题？[Q]

• 定义两种突变情形

  • 响应时间突变
  • 结构体突变

• 执行过程

  • 分组（聚类）
  • 区分突变和前体（KS和阈值）
  • 突变和前体关联
  • 排序
  • 定位low-level difference

• 相比TPROF，

  • 都是聚类分组算法，聚类分组才能比较，

    • TPROF有多种聚合层次，多了一个subspan，剩下的就是时间和结构体
    • 本文分为时间和结构体
    • TPROF如何分类前体和突变[Q]

  • 本文提出了low-level参数

1. Intro

• 性能变化通常表现为请求服务的变化

  • 突变 - 问题期间新的请求流
  • 前体

• 主要工作

  • 识别突变，根据贡献度排序，高亮最显著的分歧，定义最有可能导致问题的low-level参数

• 突变分类

  • 响应时间突变：结构相同，响应时间不同
  • 结构突变：不同路径，需要找到其原请求流然后定位根因

3. 行为改变和异常检测

• 本文注重两个时间段进行比较
• 异常检测(pinpoint)注重于找到一个集合中异常的部分

4. Spectroscope

• 4.1 分组

  • 按照结构分组（也就是字符串遍历，DFS）

  • 结构分组依据依据：

    • 类似的path会有相同的cost
    • 结构相同，字符串遍历相同

  • 对每个分类统计请求数、平均响应时间、方差，边缘延时及其方差

  • 聚类算法的优缺点

    • 聚类算法用来减少分出来类别的数量，减少开发者需要查看的类型。直接用的聚类会把突变前体（新版本中有两者）分到一起，掩盖了突变的存在
    • 无监督聚类算法 – Magpie

• 4.2 比较请求流

  • 输入：有问题阶段和无问题阶段
    使用统计测试和启发式来识别哪些包含结构突变、响应时间的突变或前体。
  • 

5. 算法 - 比较请求流

• 5.1 区分时间突变

  • KS假设检验 - 系统更改前后两个时间段，对于相同的结构，假设检验后时间段是否和前一个时间段相同
  • 非问题期和问题期作为输入；如果测试拒绝假设，则标记为包含响应时间突变
  • 为了识别导致突变的组件或者交互，spectropscope提取critical path-最长时间路径，在此path的edge上也运行假设检验

• 5.2 区分结构突变

  • 系统在改变前后的请求数类似，则，一个请求数量（在错误阶段）的增加对应着别的请求的减少（采用别的边的请求）。一个分类的请求本身数量也会抖动，所以采用一个阈值。
  • 阈值 – Spectroscope假设在非问题期和问题期运行类似的工作负载。因此，可以合理地预期，在问题期间，通过分布式系统的一条路径的请求数量的增加，应该对应于通过其他路径的请求数量的减少
  • 问题期间的分类，相比非问题之间的分类，如果包含更多的SM_THRESHOLD请求，则标记为突变，包含更少SM_THRESHOLD标记为包含前体（相同请求？相同根节点？）

• 5.3 前体和突变对应（只有结构突变才有这种对应）

  • 根节点一致

  • 数量限制

    • 剩余前体的请求数量减少 少于 结构突变请求数量增加（根节点一致为前提，且数量变化异常），就删除这个前体
    • 一个前体贡献若干变异，变异的请求数量增加少于前体请求数量减少，排除

  • 字符距离

• 5.4 排序

  • 权重：突变时间差*数量
  • 如果有多个前体，则使用平均时间加权来排序

• 5.5 寻找low-level difference

  • 识别突变前后的参数差异，来定位问题

• 5.6 缺陷

  • 不适用于争用导致的问题
  • 对于不同的负载导致的变化，必须由开发人员确定是否是正常的（不用管）

7. 处理高方差

• 假设前提是相同时间对应相同路径，所以高方差不可。

8.2 注意：比较一个东西加入前后的差异，得知道前后