Hi There
In terms of scaling out Service Broker to hundreds of instances, would it be better from a performance perspective so have one queue with all the messages coming in(obviously with a high number for max_queue readers), or create a number of queues and spread the messages across them ? Or is there no significant difference.
The one reason i am leaning towords multiple queues is so that is poison messages are found or a something lese goes wrong with a queue not all messages are affected, however creating multipple queues makes it more complex and required more administration ?
Any general best practice when it comes to this ?
Thank You
My recommendation is not to think in terms of queues, but in terms of services. Having multiple queues would require having multiple service names (since a service is bound to exactly one queue), and this would propagate down to the clients who would have to initiate the dialogs with the appropriate service. It is helpful to expose to those clients only one service name that hides the physical structure behind it. I.e. the clients always initiate the conversation with the 'Finance/Billing' service, no matter how many copies of this service physically exists. And this is how Service Broker achieves the built-in scale out option: you deploy the same service multiple times, in separate databases and/or instances. You can start with only one service/queue in a database, if you find out that it doesn't scale then you can either:
- deploy a new copy of the service in a new database on the same instance if the bottleneck is database/log I/O
- deploy a new copy of the service in a new instance on a separate machine if the bottleneck is CPU
When you add a new copy of a service all you have to do is add an appropriate route on the client and the built-in load balancing of Service Broker will take care of the rest. I'm sure you are now worried about the issue of having to update/maintain routes on thousands of clients, but you only need to update the routes on the intermediate forwarders. Rushi has a nice blog article about this: http://rushi.desai.name/Blog/tabid/54/EntryID/26/Default.aspx
HTH,
~ Remus
Hi Remus
Thanx for the feedback, i understand you view point 100%. I have laready implemented frowarders and only maintain routes on the forwarders.
This application is not for external use , it is a distributed smart client application therefore hiding the background of the servcies is not of concern.
However we may have hundreds of stores and 1 central database, the central database has to be aware of the hundred of service names for each store, if the service name is not unique it was have no idea where to go.
My main concern is the central database, it will have hundreds of remote initiator instances sending message to it. I cannot load balance this service it resides only in 1 central database. Now do all the stores send message to the same central service, thereby sending million of messages on a single queue with a very high number of queue readers configured, also if anything goes wrong with the queue everything comes to a grinding halt. Or do i create a number of queues and distribute messages from the store amongst them, for example all receipts go to the central receipt queue, all new order go to the central new order queue, this way if something goes wrong with a queue other types of transactions are getting to central. Also a single queue with millions of messages just seems a bit too much, especially a very glaring single point fo failure, but i have no idea about the scalabilty and performance of service broker.
What do you think in this scenario ?
|||Hi Remus
As i guess you have gathered performance is very important we expect very high loads.
Another advantage of multiple queues is that ic an put each on it's dedicated IO disk. So purely from a performance persoective i think multiple queues, however i would prefer 1 queue as it is much easier to administer etc.
SO yeah i am trying to get a best performance practice opinion ?
Thanx
|||Dietz wrote:
This application is not for external use , it is a distributed smart client application therefore hiding the background of the servcies is not of concern.
Even for internal apps, hiding the pysical structure behind a single logical name. You don't want to end up having to update the code of thousands of deployments in order to take advantage of the a newly deployed backend service instance.
However we may have hundreds of stores and 1 central database, the central database has to be aware of the hundred of service names for each store, if the service name is not unique it was have no idea where to go.
In don't know if it applies, but one thing to consider here is the TRANSPORT route, when the name of the service contains the routing info: http://msdn2.microsoft.com/en-us/library/ms166052.aspx. TRANSPORT routing usually goes hand-in-hand with anonymous dialog security.
Now do all the stores send message to the same central service, thereby sending million of messages on a single queue with a very high number of queue readers configured, also if anything goes wrong with the queue everything comes to a grinding halt.
Millions of messages over what period of time? Normally the queue is continuosly drained by the queue readers, they must keep up (over a long run) with the incomming rate of messages. If this is not true, then you need a bigger box on the back end.
Also, disabling the back end queue should not stops stop everything to a grinding halt. Messages send will queue up on the senders' transmission_queue until the back end is back online. The stores (POS?) have to be prepared with long delays (days?) until the response from the back end comes back.
Also a single queue with millions of messages just seems a bit too much, especially a very glaring single point fo failure, but i have no idea about the scalabilty and performance of service broker.
Queues are first class database objects, so the availability of the queue is ultimately the availability of the database. And databses can offer high availability (clustering, daabase mirroring, hardware disk mirroring etc)
And millions of messages is not that much, actually. You should do some measurements yourself, but a simple processing (RECEIVE a message, SEND a response and END the conversation) can process thousands messages/second, so it will drain a million messages in about a quarter hour. Which also means that it can sustain an incomming message rate of 1 million/15 minutes. For 1000 initiators, that is about 1 message/second. A high end back-end should be able to easily process even higher rates.
HTH,
~Remus
Hi Remus
True i agree about hiding the backend.
I am considering the TRANSPORT route, i just have test it properly.
Millions of messages per hour or so.
WHen i said brings everything to a grinding halt , what i meant was that the central database is not receieving any transaction for the stores, multiple queues may enable certain queue's for specific business requirements to continue to deliever mesages to the central environment.
I understand that service broker objects are first class and over all the availability of normal databases objects.
That's great, sounds like as long as you have decent hardware Servcie Broker can really consume an incredible number of messages.
However you have still not answered my question, what is your opinion Remus, 1 queue or a few queues for different business requirements ? Taking all of this into account.
Sounds like you are supporting the 1 queue theory but you have not really said that ?
Thanx
|||W/o knowing all details about the app, I'd probably recommend separate queues for separate business requirements.
The advantages are:
- is much easier to implement each service (as a separate procedure for each queue)
- is much easier to move services around if they don't share a queue
- one busy service (deep queue) doesn't delay other services from getting their messages
HTH,
~ Remus
No comments:
Post a Comment