NServiceBus: solution topology and scalability

Hi,

I have been playing with NServiceBus and MassTransit for a few months. One thing I have learned that is important in the design phase is to bear in mind how the system will be deployed or to code the system in a very flexible way (a project per handler?). I would have liked to be told before starting with all this technology that…  the topology matters!!!

Let me explain it with a simple example, imagine you have the following business:
– CommandA: is handled, makes something and sends a CommandB message to a different host
– CommandB: is handled, makes something and sends a CommandA2Step message to the host where the CommandA was handled. Seems logical because CommandA and CommandA2Step are related.

 

What happens if we receive 1 million CommandA messages?
The first one is executed by the CommandA handler, then it sends a command, CommandB, to another host and then it returns a CommandA2Step message to a queue with more than 999k messages! So our business is stucked in that queue.

 

 

What happens if we move to CommandA2Step to another host? It performs much better

 

 

In my tests the second option performs much better, 2 times faster, and business processes don’t get stuck in queues increasing their critical time. Of course this example is too simple but I think it explains the concept.

 

Here is the code if you want to play, just change the unicast configuration in the ServiceB app.config.

https://github.com/pablocastilla/NSBScalability

 

Regards

Advertisements

Tags: nservicebus, queues, scalability, topology