Scaling out is only useful for where the work being done by a single machine takes time and therefore more computing resources helps. To help with this, monitor the CriticalTime performance counter on the endpoint.
Some scaling out techniques improve the availability characteristic as well as throughput. When scaling out for higher availability keep in mind the components that are single points of failure e.g.
- Distributor when using MSMQ
- Message broker
and use appropriate risk mitigation technique (e.g. use failover cluster to host Distributor or cluster mode if a given broker supports one).
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 messages between the queues. The process of distributing the messages can be performed either on sender side or by a specialized proxy. Refer to the MSMQ documentation for more details regarding this particular transport.
The main difference when using broker transports (SQL Server, RabbitMQ, ASB, ASQ and SQS) is that queues are not attached to machines but rather are maintained by a central server (or cluster of servers). Such design enables usage of the competing consumers pattern for scaling out processing power. All instances connect to the same queue.
In NServiceBus 5 and below the default concurrency level is set to 1. That means the messages are processed sequentially.
Before scaling out make sure that the MaximumConcurrencyLevel has been increased in the configuration.
Increasing the concurrency on the workers might not lead to increased performance if the executed code is multi-threaded, e.g. if the worker does CPU-intensive work using all the available cores such as video encoding.