What factors affect the speed of NServiceBus message processing?

I’ve heard that question a number of times during my projects and consultings I did for several customers. Normally that generic answers can only be properly answered with information about the non-functional requirements and Service Level Agreements a certain project has to fulfill. Without knowing about your specific situation it is generally difficult to give hard numbers about the performance you can expect with a single NServiceBus endpoint. But what exactly can influence the speed of a single endpoint?

The speed of a single endpoint is influenced by the following factors: number of message processing threads, underlying hardware (mostly disk and CPU bound), the chosen transport (some transports are faster than others), the transactional level, the involvement of the Distributed Transaction Coordinator or not, the underlying saga or persistence storage (ravendb, sql…), your chosen database or IO bound operations invoked in the handler, your chosen IoC and ultimately your business logic/design of the handler code.

So those are the options you have to consider. You can now try to tweak with vertical scaling by adding more threads on the endpoint and more capable hardware (i.ex. SSD) or with horizontal scaling by adding more machines to the game (this is enough when you use brokered transports) and ultimately the distributor of you chose MSMQ as a transport. BUT depending on your non-funtional requirements, you also need to think about the underlying infrastructure. For example can you sacrifice transactional guarantees for more performance? If the answer is yes then you can tweak the transaction level and disable the Distributed Transaction Coordinator. Or even more exchange the transport with a more performant one. Throwing out the Distributed Transaction Coordinator and/or tweaking the transactional guarantees has also great impact onto how you should design your system regarding message delivering guarantees (at least once, de-duplication), idempotency and more. But this is a story for other blog posts.

You see this is a lot to think about! But without having more information about your non-functional requirements and SLAs I have to stick to this generic answer. But at least this short blog post gives hints what needs to be considered when designing your enterprise system based on NServiceBus.