I know we are not allowed to benchmark SQL Server but..... It would be nice to have material to present which demonstrates the performance gains using a queue compared to insert/delete in a SQL table.
Logically it seems faster to use a queue due to the conversation grouping locking and the service broker itself. But there seems to be some overhead involved just to manage these queues that the service broker has to perform.
I am sure we are not unique with the choice to figure out if we will get a boost in performance using SQL a queue between services rather than a table to queue data. What is available to help understand the performance gains of using a queue?
Service Broker primary goal is to provide a reliable communication infrastructure for building distributed applications. We use queues just as convenient means to store messages. If your goal is strictly to implement a queue (as in the Computer Science theory 'queue', a LIFO list), then with carefull coding and a goo design you should be able to implement one with better performance than a Service Broker queue. If on the other hand your goal is to actually communicate between applications (or between part of the same app), then Service Broker provised much more than just queues.
HTH,
~ Remus
I have been doing some testing with Service Broker and using a table as a queue. What I have found is that the method of using the table has been significantly faster than the service broker.
In our system we do not need all of the complex features of the system we are just looking for a queue with persistence support for some asynchronous processing in our application. MSMQ is not an option due to the application is installed on different versions of windows plus it operates differently depending if the server is part of a domain. We are looking to maximize performance as much as possible.
No comments:
Post a Comment