Masstransit use RabbitMQ very slow performance?

Question

I used RabbitMQ without Masstransit and sent 10,000 messages per second and a millionth message in 100 seconds.

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

The hard drive is very active (99% use) when publishing / consuming a message, and the CPU activity for this process is almost 0%.

When starting the 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 => { }); } 

Posted 100 posts in 6 seconds and I don’t know why it is very slow.

---

My machine configuration and software version:

Windows 8.1 64bit

Intel Core i3 3.30 GHz

8 GB memory

---

Visual Studio 2013 C # .Net 4.5.1

Erlang 6.3

RabbitMQ 3.4.4

Masstranzit 2.9.9

RabbitMQ.Client 3.4.0

Answer 1

This is because MassTransit expects MathTransit to expect RabbitMQ to send Ack message, making sure it was successfully received by the broker before returning to the caller. Without this expectation, if the broker fails to receive the record, the message may be lost.

With MassTransit v3 (currently in pre-release), the Publish method (and all Send methods) is now asynchronous, returning a Task that you can wait for (or not if you don't care about the results).

I could add the PublishAsync method for .NET 4.0 developers to version 2.9.9, in fact, what I can do as a temporary workaround for applications that still use the current stable version. It may also be useful to add the NoWait parameter to the SendContext , allowing the application to abandon the Ack wait behavior.

I just prefer performance longevity in my use case, to be honest.

Answer 2

I found an error in MT2 <= 2.10.1, which prevents the WaitForAck flag from WaitForAck processed WaitForAck . I posted a fix and hope Chris releases 2.10.2 as soon as possible.

Details of the problem are described here:

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

In short, the problem is caused by an error in the SendContext copy constructor, although the original context expects the ack flag to be false , the context that is used in the call always has the flag set to true .