我的应用程序严重依赖 Windows Azure 存储(而不是服务总线)中的队列。直到两天前，它还很有效，但突然间我的工作角色不再能够处理队列中的所有项目。我添加了几个计数器，并从该数据推断出从队列中删除项目是瓶颈。例如，从队列中删除单个项目最多可能需要 1 秒!
在 SO 帖子上 How to achive more 10 inserts per second with azure storage tables以及 MSDN 博客上 http://blogs.msdn.com/b/jnak/archive/2010/01/22/windows-azure-instances-storage-limits.aspx我找到了一些有关如何加快与队列通信的信息，但这些帖子只关注新项目的插入。到目前为止，我还没有找到任何关于为什么删除队列项目应该很慢的信息。所以问题是:
(1) 有人知道为什么删除突然会很慢吗？
(2) 在 Azure 的状态页面 ( https://azure.microsoft.com/en-us/status/#history ) 上，没有提及西欧(我的东西所在的地方)有任何服务中断；我可以依赖服务页面吗？
(3) 在同一个存储中，我在 blob 和表中拥有大量数据。如此大量的数据是否会干扰从队列中删除项目的能力？另外，有人知道如果您突破 2TB 的数据限制会发生什么吗？
最佳答案
1) 抱歉，没有。不是一般的。
2) 您可以信赖服务页面吗？他们当然会为您提供信息，但从问题发生到问题显示在状态板上总是有一个延迟。他们在自动化更新方面做得越来越好，并且在管理门户中，您开始看到他们会在哪里通知您，如果您的特定部署可能受到影响。话虽如此，时不时出现的小问题也并非闻所未闻，这些问题可能永远不会显示在板上，因为它们不会违反 SLA 或很快就能得到解决。不过，很高兴您检查了这一点，这通常是良好的第一步。
3) 一般来说，存储帐户中的数据量不应影响您的吞吐量；但是，存储帐户上获得的吞吐量是有限的(无论存储的数据量是多少)。您可以阅读 Storage Scalability and Performance targets ，但对于存储帐户的所有访问，吞吐量目标为每秒最多 20,000 个实体或消息。如果您有很多应用程序或系统尝试从同一存储帐户访问数据，则在接近该限制时，您可能会看到一些限制或失败。请注意，正如您在有关提高插入吞吐量的帖子中看到的那样，这些是性能目标，以及您的代码编写方式和您使用的配置对此有很大影响。存储帐户(其中的所有内容)的数据限制是 500 TB，而不是 2TB。我相信一旦达到实际存储限制，所有写入都会失败，直到有更多可用空间为止(我什至从未接近过它，所以我对此不是 100% 确定)。
吞吐量在分区级别也受到限制，对于目标为每秒最多 2000 条消息的队列，您显然根本没有得到这一点。由于您只有一个辅助角色，我猜测您也没有那么多消息生产者，至少不足以达到每秒 2,000 条消息。
我会打开storage analytics查看您是否受到限制，并检查分析打开的 $MetricsMinutePrimaryTransactionQueue 表中记录的 AverageE2ELatency 和 AverageServerLatency 值(正如 Thomas 在他的回答中所建议的那样)。这将帮助您了解一段时间内的趋势，并可能帮助确定这是否是工作角色和存储系统之间的延迟问题。
我询问辅助角色的虚拟机大小的原因是，每个虚拟机的大小有一个(未发布的)吞吐量。与较大规模的虚拟机相比，XS 虚拟机在 NIC 上获得的总吞吐量要少得多。有时，您可以通过 NIC 获得超出预期的带宽，但前提是物理机上的其他部署当时没有使用其部分带宽。这通常会导致测试时网络绑定(bind)工作出现不同的性能问题。不过，我仍然期望吞吐量比您所看到的要好得多。
关于azure - 从Azure队列中删除项目非常慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24630795/