PowerChief，识别瓶颈服务、自适应选择boosting技术、动态调整功率。

Background and Motivation

一些总结

瓶颈识别需要意识到各阶段服务实例的延迟差异--以前的工作缺乏对多阶段应用的服务实例内在延迟差异的认识，这妨碍了运行期间的准确瓶颈识别。
使用不同的提升技术，延迟的改善是不同的--不同的提升技术在加速瓶颈服务方面有其自身的优势。自适应地选择能提供更好的延迟重构的提升技术，可以在有限的功率预算内显著提高提升效率。
功率再分配需要精心设计，以支持服务提升--对有限的功率预算进行鲁莽的功率再分配，会减少瓶颈提升带来的延时改善。选择适当的服务实例以及重新分配电力预算的方式需要一个精心设计的机制。
一个运行时框架需要用来缓解多阶段应用在电力紧张情况下的响应延迟--运行时框架需要具备三个关键能力。1）在运行期间准确识别瓶颈服务；2）自适应选择提升技术以实现更好的延迟改善；3）有效地重新分配功率预算以加速瓶颈服务。

BOTTLENECK SERVICE IDENTIFICATION METHOD

Monitoring Latency Statistics

为了在运行期间监测每个服务实例的延迟统计，我们扩展了查询数据结构，以便在它走过每个服务实例时存储延迟统计。相应地，每个服务都被增强了计时能力，以衡量每个查询在排队和处理上所花费的时间。这种服务和查询的联合设计消除了服务实例和指挥中心之间的大量通信，特别是在大规模环境中部署时。同时，所有的延迟统计都是在每个服务上本地计算的，不需要全局时钟同步或特殊的硬件支持。此外，一个阶段内的服务实例可以扩展而不影响延迟监测的效果。

当一个服务实例完成处理一个查询时，它将延迟统计数据，包括实例签名（ID）、排队和处理时间，附加到扩展查询数据结构中。查询在完成所有的服务阶段时，都会携带延迟统计数据。在查询完成处理管道的最后阶段后，这些延迟统计数据被发送到指挥中心。然后，瓶颈识别器利用延迟统计数据计算延迟指标，如每个服务实例的平均和99%的排队和服务延时，然后用来驱动瓶颈识别。

其实这边没太懂，为啥比别的要好。

Identifying Bottleneck Service

在PowerChief中，我们将历史延时统计和实时负载状态结合起来，得出一个延时指标，准确地指出瓶颈服务。

延时指标=队列长度*平均排队时间+处理时间

剩下的不太相关，没看。