當使用NServiceBus使用Azure隊列時Bus.Send被阻塞

我使用Azure隊列後端測試NServiceBus。我配置使用NServiceBus所有默認設置，並有這樣的代碼來發送消息：當使用NServiceBus使用Azure隊列時Bus.Send被阻塞

while ((data = Console.ReadLine()) != null) 
{ 
    Stopwatch sw = new Stopwatch(); 
    sw.Start(); 
    Bus.Send("testqueue", new Message() {Data = data}); 
    sw.Stop(); 
    Console.WriteLine("Sent time: " + sw.ElapsedMilliseconds); 
}

當我的dev的機器上運行，它需要〜700毫秒來發送消息到隊列。直接使用Azure存儲客戶端編寫時，隊列很遠，大約350毫秒。

現在我有兩個問題：

我不想線程上Bus.Send呼叫阻塞。一種選擇是使用async \ await模式。另一種選擇是在內存隊列中傳遞消息，類似於0MQ。最後一個選項並不能保證提供當然，但假設有一些監控功能，我可以忍受。
爲什麼發送消息需要兩次簡單寫入隊列的時間？這可以優化嗎？

來源

2014-07-07 Alon Catz

數據屬性的大小是多少？

我剛剛自己運行了這個測試（使用字符串「Whatever」作爲數據），並且我發現每個遠程發送的平均延遲爲〜50ms，每15秒鐘調節一次油門，使得在該點的調用需要約300ms （這是預期的）。

請注意，azure存儲是基於遠程http的服務，因此可能因距離而延遲，但據我所知，這裏沒有公佈的性能目標。此外，它還具有主動節流功能，以便在數據移動時可以推回，這大約每15秒發生一次（請參閱我的存儲內部通信以瞭解幕後發生了什麼）

關於異步/等待。如果你的目的是疏通UI線程，比繼續前進，做這樣......

await Task.Factory.StartNew(() => _bus.Send(new Message{ 
     Whatever = data 
})).ConfigureAwait(false);

如果你的目的是實現更高的吞吐量，你應該使用更多的發送線程，而不是作爲一個線程需要無論如何要等待http響應，這是發送線程或從異步/等待中觸發的後臺線程。但請注意，無論您使用多少個發送威脅，每個隊列也會被單獨限制（以幾百個信息/秒）

PS：IT建議在.net服務點管理器上更改以下設置，以優化它對於許多小型的http請求的

ServicePointManager.UseNagleAlgorithm = false; 
ServicePointManager.Expect100Continue = false; 
ServicePointManager.DefaultConnectionLimit = 48;

希望這有助於...

來源

2014-07-09 08:52:50

感謝您的答覆。問題不在於長時間的延遲。預計從我的開發機器300毫秒。問題是沒有async \ await選項，並且在發送消息時必須阻塞線程。我們希望在一臺機器上每秒處理1000個請求。如果我們這樣做，我們將至少有1000個線程正在旋轉並等待來自NServiceBus的響應。當您執行async \ await時，線程將在等待期間釋放。否則，線程就處於等待狀態並阻塞。 –

這是在團隊雷達提供，但現在我建議你使用多個發送線程包裝發送並行爲例如 –

並使用多個隊列以及順便說一句，你將無法填充成千上萬的消息無論您使用多少個線程，都可以始終通過單個隊列 –

當使用NServiceBus使用Azure隊列時Bus.Send被阻塞

回答

相關問題