Masstransit使用RabbitMQ是非常慢的性能？

Question

I used RabbitMQ without Masstransit and send 10,000 message/per sec and One million message in 100 second.

But after using Masstransit with RabbitMQ the performance is very low in my machine.

The hard disk is very active (99% usage) when publish/consume message and CPU activity for this process is almost 0%.

When the run Publisher/Subscriber console application with this code :

var bus = ServiceBusFactory.New(x =>
{
    x.UseRabbitMq();
    x.ReceiveFrom("rabbitmq://localhost/Example_Hello");
});
var message = new MyMessage() { Text = "hello", When = DateTime.Now };
for (int i = 0; i < 100; i++)
{
    bus.Publish<MyMessage>(message, x => { });
}

Published 100 message in 6 second and I don't know why is very slow.

---

My machine's configuration and software version is:

Windows 8.1 64bit

Intel Core i3 3.30GHz

Memory 8GB

---

Visual Studio 2013 C#.Net 4.5.1

Erlang 6.3

RabbitMQ 3.4.4

Masstransit 2.9.9

RabbitMQ.Client 3.4.0

Answer 1

This is because under the covers, MassTransit is waiting for RabbitMQ to Ack the message, ensuring that it was successfully accepted by the broker before returning to the caller. Without this wait, if the broker fails to receive the write, the message could be lost.

With MassTransit v3 (currently in pre-release), the Publish method (and all Send methods) are now async, returning a Task that can be awaited (or not, if you don't care about the outcome).

I could add a PublishAsync method for .NET 4.0 developers to version 2.9.9, in fact, that's what I may end up doing as a temporary workaround for applications still using the current stable version. It may also be useful to add a NoWait option to the SendContext , allowing the application to opt-out of the Ack wait behavior.

I just favor durability over performance in my use case, honestly.

Answer 2

I have found a bug in MT2 <= 2.10.1 that prevents it from correctly handling the WaitForAck flag. I posted a patch proposal and hope Chris releases 2.10.2 as soon as possible.

The detailed information on the issue is described here:

https://groups.google.com/forum/#!topic/masstransit-discuss/XiqSDnJzd8U

In short, the issue is caused by the bug in the SendContext copy constructor, despite the original context has the wait for ack flag set to false , the context that is used in the call has the flag always set to true .