在压力测试期间，NServiceBus Timeoutsdispatcher队列中充满了消息

我正在对一个使用2次暂停的传奇故事进行压力测试。在测试过程中，大约有21K传奇被创建。这意味着有42K个超时，但我注意到，这个传奇的timeoutsdispatcher队列中有100条成千上万的消息，直到它崩溃，因为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正在向端点2发送22000条消息。
*端点2承载由该消息开始的传奇。
*每个传奇发布一个事件，然后请求2个超时：1个在4分钟，1个在10分钟

观察到的行为：
*端点1在一分钟内发送22K条消息。
*端点2（saga）每秒处理5到10条消息。
*4分钟后，将触发第一次超时，而端点2仍在处理其队列中的消息，因此仍在创建新的saga实例。
*从那一刻起，saga端点的timeoutsdispatcher队列中就充满了消息。
*大约10分钟后，timeoutsdispatcher队列已包含超过170K条消息，并且仍在填充。

---

*这种情况一直持续到端点2崩溃，因为达到了MSMQ存储限制，或者处理了输入队列中的所有消息。如果后者先出现，则timeoutsdispatcher队列消息计数开始减少，直到最终达到0。

您是否对RavenDB执行了相同的压力测试？SQL Server是在一台功能差不多相同的机器上运行的，并且具有快速的驱动器吗

更新

为你的传奇做些检查

• 是否使用了[Unique]属性，是否正确使用了该属性？换句话说，您是否为每个传入的消息使用唯一的ID？所以每一条产生2次超时的传入消息都会创建一个唯一的saga实例？如果每个传入消息都访问同一个Saga，这将是极大限制吞吐量的一个很好的例子。假设这个传奇的例子已经创建了一次，否则解释就会变得复杂。因此Message1进入数据库，尝试在数据库中查找行，查找并锁定它。第二条消息同时出现，找到该行，但该行已锁定。它将进入重试状态。Message3直到Message100出现（如果并发设置为100），所有人都尝试做相同的事情，但立即失败。您可以看到这将在一段时间内限制吞吐量：）
• Saga表和超时表上的索引是否正确
• 您的最大并发级别设置为什么

根据消息的数量，您说您发送了22k条消息，导致44k条超时消息。图像所有这些超时都在MSMQ中。想象一下，消息非常非常小，比如1Kb。NServiceBus添加的头信息可能占用2Kb。这是44000乘以3Kb，大约是135兆字节。因此，无法填充默认配额为1GB的MSMQ安装

这可能意味着您的死信队列已完全填满。并设置适当的connectionstring。比如说

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

)最后进入死信队列。此外，清除队列将使所有消息转到死信队列。除非您设置了正确的连接字符串。
您是否对RavenDB执行了相同的压力测试？SQL Server是在一台功能差不多相同的机器上运行的，并且具有快速的驱动器吗

更新

为你的传奇做些检查


是否使用了[Unique]属性，是否正确使用了该属性？换句话说，您是否为每个传入的消息使用唯一的ID？所以每一条产生2次超时的传入消息都会创建一个唯一的saga实例？如果每个传入消息都访问同一个Saga，这将是极大限制吞吐量的一个很好的例子。假设这个传奇的例子已经创建了一次，否则解释就会变得复杂。因此Message1进入数据库，尝试在数据库中查找行，查找并锁定它。第二条消息同时出现，找到该行，但该行已锁定。它将进入重试状态。Message3直到Message100出现（如果并发设置为100），所有人都尝试做相同的事情，但立即失败。您可以看到这将在一段时间内限制吞吐量：）
Saga表和超时表上的索引是否正确
您的最大并发级别设置为什么

根据消息的数量，您说您发送了22k条消息，导致44k条超时消息。图像所有这些超时都在MSMQ中。想象一下，消息非常非常小，比如1Kb。NServiceBus添加的头信息可能占用2Kb。这是44000乘以3Kb，大约是135兆字节。因此，无法填充默认配额为1GB的MSMQ安装

这可能意味着您的死信队列已完全填满。并设置适当的connectionstring。比如说

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


)最后进入死信队列。此外，清除队列将使所有消息转到死信队列。除非您设置了正确的连接字符串。
是的，我正在同一台机器上进行压力测试，就像我第一次使用RavenDb做的一样：我的本地笔记本电脑，带有嵌入式SSD。消息处理本身没有问题。saga端点运行良好，每秒处理5到10条消息。我只是看到我的传奇故事中的timeoutspispatcher队列中充斥着信息，在我的两次超时中的第一次超时的那一刻，我创建了saga's fire。我添加了对我的测试设置和观察的描述。@MarcSelis需要更多信息，或者你同意当前的答案吗？正如我的观察中所述，这肯定是超时调度队列，而不是死信队列