2

I have seen it mentioned several times as a best practice that there should be one distributor process configured per message type, but never any explanation as to why this is so. Since increasing the number of distributors increases the deployment complexity, I'd like to know the reasoning behind it. My guess is that if all available subscribers for a given message type are busy, the distributor may be stuck waiting for one to free up, while messages of other types which may have free subcribers are piling up in the distributor's work queue. Is this accurate? Any other reasons?

Adam Fyles
  • 6,030
  • 1
  • 23
  • 29
jlew
  • 10,491
  • 1
  • 35
  • 58

2 Answers2

4

It is true that the Distributor will not hand out more work until a Worker is done. Therefore if Workers are tied up with a given message type, the others will sit there until they are done. NSB doesn't have a concept of priority, all messages are created equal. Workers do not subscribe to specific message types, they just get handed work from the Distributor.

If certain message types have "priority" over others, then they should have their own Distributor. If the "priority" is all the same then adding more workers will increase performance to a certain point. This will depend upon what you are resoruce you are operating upon. If it is a database, your endpoint may be more data bound than cpu bound. In that case adding more Workers won't help as they are creating increasing contention on potentially the same resource. In this case you may need to look into partitioning the resource some how.

Adam Fyles
  • 6,030
  • 1
  • 23
  • 29
  • Aha, thank you!. I did not realize that the distributor is unable to differentiate between subscribers to different message types. So, what you're saying is that a subscriber must be able to handle all the message types that flow into its distributor? What happens if a given subscriber has no handler for a particular message type? – jlew Apr 27 '11 at 19:32
  • If a worker does not have a handler for the message type it gets ignored. – Adam Fyles Apr 28 '11 at 12:48
  • That being the case, why would it not be possible to scale by adding more workers specifically for "priority" messages (without handlers for other types?) My original assumption was that message type B processing would be blocked if all handlers of message type A were occupied, but it seems that may not be the case in a scenario with a single distributor and many workers that handle only specific message types. – jlew Apr 28 '11 at 13:00
  • Doing so negates the load balancing, you are down to one node for each type and have effectively created 2 single endpoints instead of a load balanced pair. I also confirmed that messages get dropped which is not good. This also requires you to deploy 2 different endpoints instead of just uniformly deploying the same bits. – Adam Fyles Apr 28 '11 at 14:24
1

Having one logical endpoint per message type (logical endpoint is equal to either one endpoint or many copies of an endpoint behind a distributor) allows you the flexibility to monitor and scale each use case independently.

Also, it enables you to version the endpoint for one message type independently from all the others.

There is higher deployment complexity in that you have more processes installed, and ultimately you have to strike a balance (as always) between flexibility and complexity, but keep in mind that many of these deployment headaches can be automated away.

David Boike
  • 18,545
  • 7
  • 59
  • 94
  • Thanks. So, is my conjecture correct about the performance implications of a single distributor? – jlew Apr 27 '11 at 18:33