azure的性能预测工具，主要解决改资源配置之后的性能预测。用插桩和一些定制化操作得到包含了TAP异步调用的依赖图，offline进行profile得到与应用无关的、和资源有关的、不同配置的API调用延迟分布，直接执行得到与应用有关的、和资源无关的延迟分布。 what-if中变了哪些资源，就用对应的延迟替换掉资源发生变化的部分。

本篇文章是Azure的工作。在云中部署网络应用的开发者经常需要确定服务层或运行时负载的变化会如何影响用户感知的页面加载时间。 WebPerf设计并评估了一种系统化的方法，用于在部署网络应用时解决这种"What-If"问题。给定一个网站、一个网络请求和"What-If"场景，以及假设的配置和运行时间条件，WebPerf可以估计出"假设"场景下请求的云延迟分布。

WebPerf有三个贡献：

对异步范式编写的网站进行自动插桩，以捕捉各种计算和异步I/O调用的因果关系
使用调用依赖以及各种I/O调用的在线和离线模型来估计请求的端到端延迟分布
寻找在有限时间内进行最佳测量的算法，以使建模误差最小

WebPerf的关键思想是将各种云API的、数据驱动的、离线延迟模型，与抽象为各种计算和I/O调用的因果关系（即执行顺序）的应用逻辑结合起来，以计算特定请求的总云延迟。这个想法是由两个关键的见解激发的。首先，一个请求的计算和I/O调用的因果关系在WebPerf支持的一大类假设场景中保持相对稳定。因此，有可能一次性确定依赖关系，并在重复的假设评估中重用它。其次，对许多云资源的I/O调用的延迟可以被可靠地建模为工作负载参数的函数，如存储表大小和配置参数，如地理位置和资源层，但与应用逻辑无关。因此，WebPerf可以为各种云API建立独立于应用的离线模型，作为工作负载和配置参数的函数，并在假设估计中使用这些模型。

挑战

异步
将因果关系与云API的延迟模型相结合具有挑战性。实际应用依赖关系可能很复杂。此外，云API的延迟模型最好表示为分布。
准确预测还需要许多其他的实际考虑
快速

Background and Motivation

Key Insights

Stable Dependencies：执行的因果关系相对不变。在控制路径中可能存在非确定性的情况下，WebPerf反复发出请求，并为每个独特的因果关系产生一个估计。

Application-independent API latency：对许多云资源的单个I/O调用和应用逻辑没关系，但是和资源等配置有关系。例如，Redis缓存查询API的延迟并不取决于应用程序，而是取决于其配置，如其地理位置和资源层。

WebPerf Overview

图3描述了WebPerf的各个组成部分。

输入：一个工作负载和一个假设情景。工作负载包括：（1）一个网络应用，（2）一组HTTP请求，以及（3）可选的工作负载提示，以帮助WebPerf为应用的工作负载选择合适的延迟模型。

工作流程： WebPerf的Binary Instrumenter会自动插桩给定的Web应用。然后，工作负载中的请求在被检测的应用程序上执行，产生两个信息： 1）依赖图，显示由请求执行的各种计算和I/O调用的因果关系；2）初始配置的各种计算和I/O调用的基线延时。 WebPerf还使用了一个分析器，该分析器在各种假设情况下建立各种云API的离线经验延迟分布。 WebPerf的核心是What-If引擎，它结合了依赖图、基线延迟和离线配置文件来预测在What-if场景下给定请求的云延迟分布。 WebPerf还可以将其预测的云延迟与网络延迟和客户端延迟（例如，使用WebProphet[25]进行预测）结合起来，产生端到端的延迟分布（第5.1节）。

TRACKING CAUSALITY IN TASK ASYNCHRONOUS APPLICATIONS

Tracking Causal Dependency

本篇文章对异步调用的处理是基于TAP模型的，这个模型在上一节有介绍，没放到博客里面，可以看原文。

WebPerf提取由三部分信息组成的因果关系图：

代表同步和异步计算和I/O调用的节点
代表节点间因果关系（即happens-before）的边
WhenAll和WhenAny同步点

Capturing an Execution Trace

execution trace的记录分成两步

instruments the application binary to capture the execution trace of a request
analyzes the execution trace to construct the request’s dependency graph

WebPerf自动插桩应用的二进制文件，但是有几个挑战

Tracking implicit callbacks
1. 为了跟踪一个异步调用的生命周期，我们需要将调用的开始和它的回调相关联。但是在TAP中关联困难，为此WebPerf主要利用了.NET的状态机器
Tracking pull-based continuation
1. 处理await和task completion的关系。方法是显式地插入add a continuation to the task and wrap the completion handler inside an object that saves the async id
Tracking execution forks and joins
1. 为了跟踪任务之间的同步依赖关系，WebPerf对代码进行插桩，以此完成intercept，从传给相关函数的参数地方提取ID
Tracking non-TAP calls
1. 用一些简单的方式追踪除了async-await类型之外的异步调用

Extracting dependency graphs

一个请求的依赖图是一个有三种类型节点的有向无环图：Start，End，和Task。Start和End表示请求的开始和结束。 Task代表异步API调用，以及其他同步和非同步的计算和I/O调用。

EVALUATING WHAT-IF SCENARIOS

Application-independent Profiling

WebPerf维护一个profile字典，其中包含不同配置和输入下的不同云API延迟的profiles或统计模型。 WebPerf使用两种类型的profiles：独立的和参数化的，根据它们是否依赖于工作负载参数来区分。

Workload-independent profiles。 WebPerf反复调用API，直到获得足够好的延迟分布。

Parameterized profiles。少数云API的性能取决于工作负载。例如，Azure SQL的查询API根据具体的查询（例如，是否有连接）和表的大小表现出不同的延迟。 WebPerf为这些API中的每一个建立了多个profile，并以相关的工作负载参数为参数。

Application-specific Profiling

WebPerf在一个插了桩的应用程序上执行一个给定的请求，以收集其依赖图。它还会多次执行请求，以捕获特定于application-specific, baseline latency distribution of each task of the graph。

What-if Engine

给定依赖图，WebPerf首先估计每个任务节点的延迟分布，然后通过结合每个任务的延迟分布估计请求的总延迟分布。挑战如下

Profile selection。 WebPerf使用以下工作流程为依赖关系图中的每个节点选择合适的profile。 (1) 如果节点（即节点中调用的API）不受假设情况的影响，WebPerf使用API的基线profile作为其估计延迟分布。 (2) 如果节点受到what-if场景的影响，WebPerf会检查API是否有一个参数化的profile，并且开发者已经提供了适当的工作负载提示。如果是这样，WebPerf选择正确的带参数的profile作为其估计延迟。否则，它使用API的independent profile作为估计的延迟。

Enforcing concurrency limits。一些云计算API有隐式或显式的并发限制。为了考虑到这种排队延迟，WebPerf修改了给定的依赖图，以施加并发限制。对于一个已知的系统范围内对特定I/O的最大n个并发调用的限制和r个并发用户请求的负载，WebPerf对每个请求施加n/r个并发调用的限制。然后，它自上而下地遍历请求的依赖图，并检查是否有任务达到n/r的限制；如果有，它将该任务（连同其所有的后代）从其父代中移除，并将其作为WhenAny子代加入其限制内的兄弟姐妹中。

Probabilistic estimation。最后，WebPerf结合对依赖图中所有任务的估计延迟分布，产生一个总的云延迟分布。该算法是自下而上的，并通过依赖图的末端节点来调用。给定一个节点，它根据基线延迟（如果该节点不受what-if场景的影响，或者该节点依赖应用程序）或离线profile（其他情况下）估计其延迟。然后，它递归地计算每个路径的延迟分布，并根据同步点的语义将其合并。