Scaling out MSMQ endpoints

Component: MSMQ Transport
Standard support for version 6.x of NServiceBus has expired. For more information see our Support Policy.

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 messages between the queues.

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

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

The following table compares each approach:

Sender-Side DistributionDistributor
Sender aware of scaled-out receiverSender ignorant of scaled-out receiver
Almost linear 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
Available since core v6 & msmq v1Unsupported since core v7 / msmq v1
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.
Using the 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 rolls back to the queue and other machines could then process it.

One 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