NServiceBus Timeoutsdispatcher隊列在壓力測試期間被消息充斥

Question

我正在對使用2個超時的傳奇進行一些壓力測試。在測試期間，大約21K傳奇的被創造。所以這將意味着42K超時，但我注意到，傳奇的timeoutsdispatcher隊列正在充斥着數以百計的數千條消息，直到它崩潰，因爲MSMQ存儲限制被擊中。

自從我將持久性機制從RavenDB切換到SQL Server後，我看到了這種行爲。

有沒有人有一個想法什麼可能是錯的？

交通：MSMQ
持久性：使用NHibernate的 套餐：

NHibernate version 4.0.4.4000 
NServiceBus version 5.2.14 
NServiceBus.Host version 6.0.0 
NServiceBus.Log4Net version 1.0.0 
NServiceBus.NHibernate version 6.2.7 

測試設置：
*端點1發送22000個消息到端點2.
*端點2名的主機開始工作一段傳奇通過那個消息。
*每個傳奇發佈一個事件，然後請求2個超時：1在4分鐘，1在10分鐘。

觀察到的行爲：
*端點1在一分鐘內發送了22K條消息。
*端點2（傳奇）每秒處理5到10條消息。
* 4分鐘後，第一次超時被觸發，而端點2仍在處理來自其隊列的消息，因此仍在創建新的saga實例。
*從那一刻開始，傳奇端點的timeoutsdispatcher隊列正在充滿消息。
* 10分鐘左右後，timeoutsdispatcher隊列已經包含超過170K條消息，並且仍然填滿。
*繼續進行，直到端點2崩潰，因爲命中MSMQ存儲限制或處理來自輸入隊列的所有消息。如果後者發生在第一位，則timeoutsdispatcher隊列消息計數開始減少，直到最終達到0.

Answer 1

您是否使用RavenDB執行相同的壓力測試？ SQL Server在一臺或多或少同樣強大的計算機上運行速度很快？

更新

一些檢查你的傳奇

• 是否使用了[獨特]屬性，它被正確使用？換句話說，你是否對每個傳入消息使用唯一標識符？所以每一個產生2個超時的傳入消息都會創建一個獨特的saga實例？如果每個傳入的消息都訪問相同的Saga，這對於極其有限的吞吐量將是一個很好的例子。想象一下，Saga實例已經創建了一次，否則解釋會變得複雜。因此，Message1進來，試圖找到數據庫中的行，找到並鎖定它。第二條消息同時進入，找到該行但被鎖定。它會重試。 Message3直到Message100進入（如果併發設置爲100）並且所有嘗試做同樣的事情，立即失敗。你可以看到這會限制吞吐量一段時間:)
• 您的佐賀表和超時表的正確索引？
• 您的最大併發級別設置爲？

根據消息的數量，你說你發送22k消息，導致44k超時消息。圖像所有這些超時都在MSMQ。想象一下，消息真的非常小，比如1Kb。由NServiceBus添加的標頭信息可能需要2Kb。這是44.000次3Kb大約是135兆字節。因此，沒有辦法填充默認配額爲1GB的默認MSMQ安裝。

這可能意味着您的死信隊列被完全填滿。 Find more information on MSMQ connectionstrings並設置適當的連接字符串。例如

<connectionStrings> 
    <add name="NServiceBus/Transport" 
    connectionString="deadLetter=false;journal=false;"/> 
</connectionStrings> 

消息使用TimeToBeReceived屬性集（link）在死信隊列結束。同時清除隊列將使所有消息進入死信隊列。除非你設置了正確的連接字符串。