MQBench.exe Measures Time to Deliver MSMQ Messages (186194)

MORE INFORMATION

The following file is available for download from the Microsoft Download Center:
For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base: Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.

Sample Command Line and Output

Use the following syntax to run MQBench:

   mqbench -sr 100 100 -p .\q1 -t 10

   Total messages: 1000 Sent
   Test time:      6.900 seconds
   Benchmark:      145 messages per second
   Throughput:     14493 bytes per second
				

This benchmarks 1,000 recoverable messages sent to a local queue using 10 threads. Each message body contains 100 bytes.

To see a full the description of the command-line options, use the following command:

   mqbench /?
				

To install this file, simply copy the extracted executable to the location from which you wish to launch it. The source code for the tool is also included in the compressed file.

Performance Considerations When Using MQBench

• During benchmark, do not send more messages than the available RAM will hold. This may produce incorrect benchmark results, because the system will always page. This is not a user scenario for performance because messages do not continue to accumulate, and if the MSMQ client holds a backlog, only the active portion remains in RAM.
• When running message performance benchmark tests, the first benchmark will always yield low performance results. This occurs because MSMQ allocates message files to store the messages in this first run. This allocation is separate for express, recoverable, and journalized messages. To obtain the stable state benchmark results, you should exclude the benchmark results from the first run and start collecting from the second run. You should send and receive all the messages in the first benchmark run, but take the benchmark results from the second run. This is true for both local or network benchmarks.
• Even if your main concern is benchmarking, you should always receive all the messages you are sending. This prevents messages from accumulating, which leads to poor performance due to paging. Do not purge the queue, but receive the messages programmatically. Purged transactional messages will not leave the message store, but will go to the Dead Letter Queue instead, while still consuming pages.
• When benchmarking recoverable message delivery, having the receiver running boosts performance, because no disk access is performed. Having a multi-threaded receiver (or using overlapped receive) will result in an addition performance increase, because another thread is available and waiting for a new message while the first one is processing the received message. This is true for local cases, but may also apply to a a receiver over a network connection.
• When measuring network delivery, always use the -w switch when you run Mqbench.exe file on the receiver. The switch makes the utility wait for the first message before it starts the benchmark, which excludes the session establishment time from the benchmark results.

For additional information about Microsoft Message Queue Server performance, please see the "MSMQ Administrator's Guide."

For general information about Microsoft Message Queue Server, see the Microsoft Web site at