NServiceBus Saga - 如何配置 millisToSleepBetweenMessages?

发布于 2024-11-18 22:58:30 字数 252 浏览 1 评论 0原文

我是 C# 新手,我正在一个使用 NServiceBus Saga 的项目中工作。

在传奇的逻辑中,如果未满足条件,则将调用 RequestTimeout 方法 1 分钟。

问题是这个调用消耗了太多的处理器,我认为这是因为 TimeoutManager 使用默认值 10 毫秒来检查时间是否到了并将超时消息发送回 saga。

有谁知道如何更改此 millisToSleepBetweenMessages 属性?

提前致谢!塞巴

I'm new in C# and I'm working in a project where an NServiceBus Saga is being used.

Inside the logic of the saga, the RequestTimeout method is being called for 1 minute if a condition is not achieved.

The problem is that this call consumes too much of the processor and I think this is because the TimeoutManager use the default value of 10 millisenconds to check if the time is up and send back the time out message to the saga.

Does anybody knows how this millisToSleepBetweenMessages property could by changed?

Thanks in advance! Seba

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

旧话新听 2024-11-25 22:58:30

我收集您当前使用的 TimeoutManager 是 2.0 或 2.5 版本。如果是这种情况,TimeoutManager 端点本身就有一个带有 appSetting 的配置文件 (Timeout.MessageHandlers.dll.config)。

下面是一个示例:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="MsmqTransportConfig" type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core" />
  </configSections>

  <MsmqTransportConfig
    InputQueue="timeoutmanager"
    ErrorQueue="error"
    NumberOfWorkerThreads="1"
    MaxRetries="5"
  />

  <appSettings>
    <!-- relevant for a Serialization of "xml" only -->
    <add key="NameSpace" value="http://www.UdiDahan.com"/>

    <!-- can be either "xml", or "binary" -->
    <add key="Serialization" value="xml"/>

    <!-- default is 1000, influences memory use (16 bytes / saga ID) -->
    <add key="MaxSagasIdsToStore" value="10000"/>

    <!-- default is 10, decreasing this value gives better time resolution but higher IO churn -->
    <add key="MillisToSleepBetweenMessages" value="10"/>

  </appSettings>

</configuration>

在此版本的超时管理器中,您有一个选择。您可以调整 MillisToSleepBetweenMessages,这只会调整超时管理器处理的每条消息的 Thread.Sleep() 超时。如果超时时间非常短,那么当消息被放回到队列中并一遍又一遍地重新处理时,这确实会导致大量的混乱。

您可以将其调整为更高的值,例如 1000 毫秒,但请记住,您会损失很多时间准确性,尤其是在发生大量超时的情况下。如果您对通过此超时管理器的所有用例的要求都是 1 分钟超时,无论给予还是接受,那么都可以。

否则,您有几个选择:

  • 查看未发布的 NServiceBus 3.0 代码,其中正在开发经过大幅改进的 TimeoutManager。
  • 看一下我的博客文章 NServiceBus TimeoutManager Revisited,其中我有一个在生产场景中使用的超时管理器的实现。请记住,它不是为多个站点或多个时区或任何此类问题而设计的,但它确实解决了被迫放弃准确性以减少客户流失的问题。

I gather the TimeoutManager you're currently using is either the 2.0 or 2.5 version. If this is the case, the TimeoutManager endpoint itself has a config file (Timeout.MessageHandlers.dll.config) with an appSetting.

Here's an example:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="MsmqTransportConfig" type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core" />
  </configSections>

  <MsmqTransportConfig
    InputQueue="timeoutmanager"
    ErrorQueue="error"
    NumberOfWorkerThreads="1"
    MaxRetries="5"
  />

  <appSettings>
    <!-- relevant for a Serialization of "xml" only -->
    <add key="NameSpace" value="http://www.UdiDahan.com"/>

    <!-- can be either "xml", or "binary" -->
    <add key="Serialization" value="xml"/>

    <!-- default is 1000, influences memory use (16 bytes / saga ID) -->
    <add key="MaxSagasIdsToStore" value="10000"/>

    <!-- default is 10, decreasing this value gives better time resolution but higher IO churn -->
    <add key="MillisToSleepBetweenMessages" value="10"/>

  </appSettings>

</configuration>

In this version of the Timeout Manager, you have a choice. You can adjust MillisToSleepBetweenMessages, and that just adjusts the Thread.Sleep() timeout on each message the Timeout Manager processes. With a very small timeout, this does cause a lot of churn as the message is put back on the queue and reprocessed over and over.

You can adjust it to something higher like 1000ms, but keep in mind that you will lose a lot of your time accuracy, especially if there are lots of timeouts going on. If your requirements for ALL use cases going through this timeout manager are for a 1-minute timeout, give or take, then that's fine.

Otherwise, you have a few choices:

  • Take a look at the unreleased NServiceBus 3.0 code, where a much improved TimeoutManager is under development.
  • Take a look at my blog post NServiceBus TimeoutManager Revisited, where I have an implementation of a Timeout Manager that I use in my production scenarios. Keep in mind it isn't designed for multiple sites or multiple time zones or any of those types of issues, but it does solve the issue of being forced to give up on accuracy to reduce churn.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文