蔚蓝云队列的可伸缩性

Question

在当前项目中，我们当前使用8个并行的工作角色机器，它们实际上有点像不同的，而不是azure可能期望的。

该系统的短概要：

• 每个工人开始到实际连接至云队列8个处理和处理消息
• 每个进程访问三种不同的云队列用于收集消息用于不同的目的（增量识别，备份和元数据）
• 每条消息都会导致WCF调用ERP系统来收集信息，并最终在ReDis缓存中添加retreived响应
• 此方法已被选择在许多小型机器上由于成本和性能的原因。虽然24台单核机器对ERP系统的执行速度为400次/秒，但8台四进制8台机器每秒可执行800次以上的呼叫。

现在回答这个问题：当增加机器数量以将性能提高到1200个调用/秒时，我们经历了Cloud Queue的中断。在同一时刻，80％的机器进程不再处理消息。

在这里，我们有两个问题：

1. 远程调试是不可能的这些过程，但它是可以使用dile得到一些信息出来。
2. 我们使用Cloud Queue的GetMessages方法从队列中取得4条消息。 Cloud Queue始终以0消息回应。重新连接云队列没有帮助。

重新启动工人确实有帮助，但很快就会导致同样的问题。 我们是否碰到了Cloud Queue的可扩展性的自然结局，并且应该切换到Service Bus？

更新：

我一直没能完全理解这个问题，我在the natual borders of Cloud Queue描述它。

总结：

• TCP连接的计数都十分可观。其实太令人印象深刻（多几百个）
• 再回到原先的容量让系统恢复正常

Answer 1

操作。在我的经​​验，我已经能够得到更好的原始性能了Azure的云队列比服务总线，但Service Bus具有更好的企业功能（可靠性，主题等）。 Azure云队列应该每个队列最多处理2K /秒。

https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/

您也可以尝试分区到多个队列，如果有一些自然的分区键。

确保你的进程没有某种形式的线程死锁是真正的罪魁祸首。您可以通过在队列挂起并试图从队列中提取消息时连接到队列来测试此情况。如果可行的话，这是你的过程，而不是队列。

也看看这个设置一些其他显示器： https://azure.microsoft.com/en-us/documentation/articles/storage-monitor-storage-account/

Answer 2

它花了一些时间来解决这个问题：

首先，存储帐户的使用情况的总结：

• 我们每天都会使用blob存储一次。
• Azure提供的“正常”对角线也使用相同的存储帐户。
• 一些控制进程使用小表来存储和读取信息每小时一次ca。 20分钟
• 可能会有多达800个呼叫/秒，试图增加一个号码来统计对ERP系统的呼叫。

当确认存储帐户处于重负载状态时，我们将其分解。

• 现在有三个物理存储帐户可以堆满2个队列。
• 原来人们依然可以保持高达800/s的呼吁增加柜台
• Diagnositics公司仍然在原来的
• 控制信息一直也感动

该系统已运行了2周，像魅力一样工作。我们从中学到了几件事：

• 不，基础设施“不只是在那里”，它不能无限缩放。
• 即使我们认为我们没有使用“那么多”总结，我们使用相当沉重和不受控制。
• 网络中任何地方都没有“最佳实践”来讲述整个故事。 ESP。当开始使用存储帐户时，来自MS的指南将非常有帮助

存储中的异常处理非常糟糕。即使存储帐户被过度使用，我希望某种异常的不只是返回零消息没有任何周边信息 这里阅读完整的故事：natural borders of cloud storage scalability

UPDATE： 可扩展性有很大影响。您可能对Azure Service Bus: Massive count of listeners and senders感兴趣，以了解一些更多的陷阱。