我的应用程序在很大程度上依赖于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的数据限制会发生什么？
答案 0 :(得分：2)
1）抱歉，没有。不是一般的。
2）你能依靠服务页面吗？它们当然会为您提供信息，但是从问题发生到状态板上的时间总是存在延迟。他们在自动化更新方面做得越来越好，而在管理门户中，如果您的特定部署可能受到影响，您将开始看到他们将通知您的位置。话虽如此，并不是闻所未闻的那些小问题不时出现，可能永远不会出现在董事会上，因为它们不会破坏SLA或者很快得到解决。你检查这个很好，这通常是一个很好的第一步。
3）通常，存储帐户中的数据量不会影响您的吞吐量;但是，存储帐户的吞吐量有限（无论存储的数据量如何）。您可以阅读有关Storage Scalability and Performance targets的信息，但吞吐量目标最多可达20,000个实体或每秒访问存储帐户的消息。如果您有大量应用程序或系统尝试从同一存储帐户访问数据，则在接近该限制时，您可能会看到一些限制或失败。请注意，正如您在帖子中看到的那样，提高了插入的吞吐量，这些是性能目标以及代码的编写方式以及您使用的配置会对此产生严重影响。存储帐户（其中的所有内容）的数据限制为500 TB，而不是2 TB。我相信一旦你达到了实际的存储限制，所有的写入都会失败，直到有更多空间可用（我从来没有接近它，所以我不是百分之百确定）。
吞吐量也受限于分区级别，对于每秒最多2000条消息的目标的队列，您显然根本没有这样做。由于你只有一个工作者角色，我会猜测你没有那么多的消息生产者，至少不足以接近每秒2,000个消息。
我打开storage analytics以查看您是否受到限制以及检查AverageE2ELatency和AverageServerLatency值（正如Thomas在他的回答中所建议的）被记录在$ MetricsMinutePrimaryTransactionQueue表中，分析转向上。这将有助于您了解一段时间内的趋势，并可能帮助确定它是否是工作者角色与存储系统之间的延迟问题。
我询问有关工作者角色的VM大小的原因是每个VM的吞吐量（未发布）基于其大小。与较大的大小相比，XS VM在NIC上的总吞吐量要少得多。有时，您可以通过NIC获得比预期更多的内容，但前提是物理计算机上的其他部署当时没有使用其部分带宽。在测试时，这通常会导致网络绑定工作的性能问题不同。我仍然期望比你看到的更好的吞吐量。
答案 1 :(得分：1)
您和Azure存储之间存在网络，这可能会降低延迟。
突然出现峰值（例如从20ms到2s）可能经常发生，因此您需要在代码中处理此问题。
要进一步查明此问题（例如客户端问题，网络错误等）。您可以启用存储分析以查看问题所在。在那里你还可以看到end2end延迟是否太大，或者只是服务器延迟是限制因素。前者通常讲述网络问题，后者关于队列本身的错误。
通常这些延迟会发生瞬态（只是暂时的），并且不需要宣布这是一种服务中断，因为它不是一种。如果性能持续不佳，您应该打开支持票。