performance testing

I would like to test some servers. Is there a simple testtool to benchmark
performance. I would like to have it tested on a Itanium 64 bits server and
32 bit server to forcast the performance gain. Besides the server switch the
San will also be upgraded.
Does any one have predifined query's ?SQL&Sap wrote:
> I would like to test some servers. Is there a simple testtool to
> benchmark performance. I would like to have it tested on a Itanium 64
> bits server and 32 bit server to forcast the performance gain.
> Besides the server switch the San will also be upgraded.
> Does any one have predifined query's ?
Pre-defined queries won't really tell you how much of an improvement, if
any, you are going to see moving from one server to another. In fact,
they could serve to inflate expectations. For that type of information,
a simple reference to tpc.org benchmarks or the manufacturers claim of
TPS would suffice.
I strongly suggest you test your own database and applications on the
new server and compare to the old one in terms of SQL performance.
It's easy to assume that because you're moving from a 32-bit Intel
system to a 64-bit Itanium one, that the performance will be faster. And
on paper, that's probably true. But SQL performance is a different beast
and it's best to test what you plan to run on the server.
If you can come up with a set of queries that you either run manually
or, better yet, are run from existing applications, you can use a tool
like Profiler or Speed Coefficient from Imceda to benchmark your SQL
performance on both systems and compare the results.
David Gugick
Imceda Software
www.imceda.com

Performance of a Queue vs Table

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.

Performance of a Queue vs Table

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.