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）在死信队列结束。同时清除队列将使所有消息进入死信队列。除非你设置了正确的连接字符串。