从 Azure 队列中删除项目非常缓慢

Question

我的应用程序严重依赖于 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 的数据限制会发生什么？

Answer 1

1) 对不起，不。不是一般的。

2) 你能依赖服务页面吗？他们当然会为您提供信息，但从问题发生到它出现在状态板上总是存在延迟。他们在自动化更新方面做得越来越好，在管理门户中，您开始看到如果您的特定部署可能受到影响，他们会在哪里通知您。话虽如此，不时出现小问题并非闻所未闻，这些小问题可能永远不会显示在板上，因为它们不会破坏 SLA 或得到极快的解决。很高兴你检查了这个，这通常是一个很好的第一步。

3) 通常，存储帐户中的数据量不会影响您的吞吐量；但是，您在存储帐户上获得的吞吐量是有限制的（无论存储的数据量如何）。您可以阅读有关Storage Scalability and Performance targets 的信息，但吞吐量目标是存储帐户的所有访问每秒最多 20,000 个实体或消息。如果您有很多应用程序或系统试图从同一个存储帐户访问数据，那么当您接近该限制时，您可能会看到一些限制或失败。请注意，正如您在有关提高插入吞吐量的帖子中看到的那样，这些是性能目标，以及您的代码编写方式和您使用的配置对此有重大影响。存储帐户（其中的所有内容）的数据限制为 500 TB，而不是 2TB。我相信一旦达到实际存储限制，所有写入都会失败，直到有更多可用空间（我什至从未接近它，所以我不能 100% 确定这一点）。

吞吐量在分区级别也受到限制，对于目标为每秒最多 2000 条消息的队列，您显然根本没有得到。由于您只有一个工人角色，我猜您也没有那么多消息生产者，至少不足以接近每秒 2,000 条消息。

我会打开 storage analytics 以查看您是否受到限制，并检查记录在分析打开的 $MetricsMinutePrimaryTransactionQueue 表中的 AverageE2ELatency 和 AverageServerLatency 值（正如 Thomas 在他的回答中所建议的那样）。这将有助于您了解一段时间内的趋势，并可能有助于确定这是否是辅助角色和存储系统之间的延迟问题。

我询问辅助角色的 VM 大小的原因是每个 VM 的吞吐量（未发布）数量取决于其大小。 XS VM 在 NIC 上获得的总吞吐量比更大的 VM 少得多。有时您可以通过 NIC 获得比您预期的更多，但前提是物理机上的其他部署当时没有使用它们的带宽部分。在测试时，这通常会导致网络绑定工作出现不同的性能问题。不过，我仍然希望吞吐量比您看到的要好得多。

Answer 2

您和 Azure 存储之间存在网络，这可能会降低延迟。

突然的峰值（例如从 20 毫秒到 2 秒）可能经常发生，因此您需要在代码中处理这个问题。

要进一步查明此问题（例如客户端问题、网络错误等），您可以打开存储分析以查看问题所在。在那里您还可以查看端到端延迟是否太大或只是服务器延迟是限制因素。前者通常讲述网络问题，后者讲述队列本身的问题。

这些延迟问题通常是暂时的（只是暂时的），没有必要将其宣布为服务中断，因为它不是一个。如果它的性能一直很差，你应该开一张支持票。