Scaling out MSMQ endpoints

Component: MSMQ Transport
NuGet Package NServiceBus (6.x)

In bus transports like MSMQ there is no central place from which multiple instances of an endpoint can receive messages concurrently. Each instance has its own queue so scaling out requires distributing of the messages between the queues.

The process of distributing the messages can be performed on the sender side. In this case the sender of the message knows about all the instances of the receiver. Refer to the Scaling out with sender-side distribution article for more details.

Distribution can be also done via a dedicated distributor process. Refer to Scaling out with distributor for details.

Following table compares both approaches:

Sender-Side DistributionDistributor
Sender aware of scaling-out of receiverSender ignorant of scaling-out of receiver
Almost liner scaling with number of workersLimited scaling
No flow controlFlow control via ready messages
No automatic worker failure detectionWorker failure detection via ready messages
Round-robin load balancingFair load balancing
A scaled-out endpoint without a Distributor cannot subscribe to events published by an endpoint running Version 5 or lower of NServiceBus, otherwise each event will be delivered to each instance. The workaround is to put a Distributor in front of the scaled-out endpoint. Rrefer to the distributor sample for details).
Using Sender-Side distribution feature in combination with the Distributor will affect the routing of delayed retries. These messages will be routed directly to the Distributor instead of the endpoint instance even though these messages were originally sent to the endpoint instance.

MSMQ remote receive

Version 4 of MSMQ, made available with Vista and Server 2008, can perform remote transactional receive. This means that processes on other machines can transactionally pull work from a queue on a different machine. If the machine processing the message crashes, the message roll back to the queue and other machines could then process it.

The biggest problem with 'remote transactional receive' is that it gets proportionally slower as more worker nodes are added. This is due to the overhead of managing more transactions, as well as the longer period of time that these transactions are open. In short, the scale out benefits of MSMQ Version 4 by itself are quite limited.

Related Articles

Last modified