performance - 与 RavenDB 相比，使用 MSMQ 作为 Nservicebus 的订阅存储时吞吐量有很大差异

Question

最近我们注意到我们的 Nservicebus 订阅者无法处理不断增加的负载。我们有相当稳定的事件输入流(来自嵌入式设备的测量数据)，因此吞吐量跟随输入非常重要。

经过一些分析后，我们得出结论，花费大量时间的不是事件处理，而是检索和发布事件的 NServiceBus 过程。为了更好地了解发生了什么，我重新创建了 Pub/Sub 示例 ( http://particular.net/articles/nservicebus-step-by-step-publish-subscribe-communication-code-first)。

在我的笔记本电脑上，使用所有 NServiceBus 默认值，Ordering.Server 的最大吞吐量约为 10 个事件/秒。它唯一做的就是

class PlaceOrderHandler : IHandleMessages<PlaceOrder>
{
    public IBus Bus { get; set; }

    public void Handle(PlaceOrder message)
    {
        Bus.Publish<OrderPlaced>
            (e => { e.Id = message.Id; e.Product = message.Product; });
    }
}

然后我开始尝试配置设置。似乎没有人对此(非常低的)性能产生任何影响:

Configure.With()
           .DefaultBuilder()
           .UseTransport<Msmq>()
           .MsmqSubscriptionStorage();

通过这种配置，吞吐量立即上升到 60 条消息/秒。

我有两个问题:

1. 使用MSMQ作为订阅存储时，性能比RavenDB好很多。为什么像订阅数据存储这样微不足道的事情会产生如此大的影响？

2. 我原以为会有更高的性能。我应该使用任何其他配置设置来获得比这至少好一个数量级的设置吗？在我们的服务器上，运行此示例时的最大吞吐量约为 200 msg/s。对于一个甚至还没有做任何有用的事情的系统来说，这远非壮观。

Answer 1

MSMQ 没有 native 发布/订阅功能，因此 NServiceBus 通过存储订阅者列表然后遍历该列表向每个订阅者发送事件副本来添加支持。这转化为 X 消息排队操作，其中 X 是订阅者的数量。这解释了为什么 RabbitMQ 更快，因为它具有 native pub/sub，因此您只需要对代理进行一次操作。

基于 msmq 队列的存储速度更快的原因是它是本地存储(如果需要横向扩展端点则不能使用)，这意味着我们可以缓存数据，因为那不可能是任何数据其他端点实例更新存储。简而言之，这意味着我们可以摆脱内存查找，如您所见，这是最快的选择。

有计划在所有存储中添加 native 缓存:

https://github.com/Particular/NServiceBus/issues/1320

200 msg/s 听起来很低，如果你跳过 bus.Publish，你会得到多少？ (只是为了得到一个基线)