Azure接受了弹性伸缩的概念，我已经能够通过我的工人角色实现这一点。但是，当涉及到我的Web角色(，例如MVC应用程序)时，我不确定要监视什么(<em]或如何>，以确定何时是增加(或减少的运行实例数量)的好时机。我假设我需要监视一个或多个性能计数器，但不确定从哪里开始。
有人能推荐一种最佳实践来评估MVC Web角色实例相对于扩展决策的负载吗？
这个问题有点开放，因为监控通常是特定于应用程序的。话虽如此：
从您在本地服务器上查看的简单度量开始，表示应用程序的KPI。例如：也许看看网络利用率。这篇TechNet文章描述了System Center for Windows Azure收集的性能计数器。例如：
- ASP。NET应用程序请求/秒
- 网络接口字节
- 接收/秒
- 每秒发送的网络接口字节数
- 处理器%处理器时间总计
- 逻辑磁盘可用MB
- LogicalDisk%可用空间
- 可用内存MB
您可能还想查看排队的请求数和请求等待时间。
网络利用率很有意思，因为您的NIC每个核心提供大约100Mbps的带宽，即使CPU和其他资源未得到充分利用，也可能成为瓶颈。您可能需要扩展到更多的实例来处理高带宽场景。
此外：我倾向于不太重视CPU利用率，尽管它很容易测量(并且在示例中经常出现)。在接近容量的情况下运行CPU通常是一件好事，因为你正在为此付费，并且可能会尽可能多地使用它。
至于减少：这需要更加小心地处理。Windows Azure计算按小时计费。例如，如果您在11:50扩展到一个额外的实例，并在12:10再次扩展，那么您只需要花费两个cpu小时。此外：你不想扩大规模，然后进行新的测量，并决定现在可以再次缩小规模(有效地创建了一个不断增加和减少实例的脉冲)。为了让事情变得更容易，可以考虑企业库中的自动调整应用程序块(WASABi)。这包含了所有的比例规则(比如我刚才提到的)，使用起来非常简单。