Azure 队列性能突然下降答案

【问题标题】：Sudden dropoff in Azure queue performanceAzure 队列性能突然下降
【发布时间】：2014-07-23 00:20:54
【问题描述】：

简短版：Azure 队列请求超时率突然、剧烈且看似永久地增加的原因是什么？

在这里提供所有可能相关的细节是很困难的，但这是一个开始：

这是一个 Azure 应用程序 (SDK v2.0)，其 WCF 服务将工作请求放在一个队列中（每天大约 10 万次调用）和几个处理队列的工作角色。我们使用最新的 .NET 代理 (3.3.38) 进行了 New Relic 监控。

我们在几天前部署的最新版本中遇到了一个问题 - 在它正常运行大约 24 小时后，突然之间，当我们的工作角色获取消息时，我们开始看到超时率大大增加来自队列，以及吞吐量的灾难性下降（我们的应用程序现在使用 40 个工作人员几乎无法跟上它自己的队列，而通常只有 2 个工作人员就可以了！）自从超时开始，他们没有表现出放松的迹象，自它开始发生以来一直保持相同的速度。

来自 New Relic 的几张图片来说明：

虽然这些信息不足以提供一个好的答案，但我只是想弄清楚我可以从哪里开始寻找。我已经收到了 New Relic 和 Microsoft 的支持票，但我们也在尝试自己进行调查。这可能是节流吗？我的队列处理器工作人员角色中的某种资源耗尽？我们没有看到 WCF 服务的负载增加，并且我们没有更改 Azure 客户端库或更改处理队列的代码中的大部分内容。

【问题讨论】：

我会回滚您的应用程序更新，看看您是否恢复正常服务。如果您无法做到这一点，我将仔细检查可能导致阻塞呼叫的任何事情。在代码的关键区域添加大量检测，看看是否有一个共同的地方代码需要很长时间才能执行。
自从注意到它在我们的测试环境中也出现以来，我已经能够缩小问题的范围：它是 CloudQueue.DeleteMessage 调用超时（不是每次，只是间歇性，但经常足以引起问题）。不久将进行一些适当的编辑或将其移至新问题。

标签： azure azure-storage

【解决方案1】：

我建议您对存储帐户启用分析，以确定瓶颈是服务器端还是客户端/网络相关。具体来说，您可以查看存储分析指标表 - AverageE2ELatency 和 AverageServerLatency 属性，以检查问题是服务器端还是客户端。

您可以通过以下链接了解有关 Azure 存储分析的更多信息

概述： http://msdn.microsoft.com/en-us/library/hh343270.aspx

如何在门户中启用： http://azure.microsoft.com/en-us/documentation/articles/storage-monitor-storage-account/

指标表架构： http://msdn.microsoft.com/en-us/library/hh343264.aspx

博文： http://blogs.msdn.com/b/windowsazurestorage/archive/2011/08/03/windows-azure-storage-analytics.aspx

【讨论】：