蔚藍雲隊列的可伸縮性

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感興趣，以瞭解一些更多的陷阱。