Navigation

	Home Page
	Index
	All Pages

Quick Search
Advanced Search »

Contributor Links

	Create a new Page
	Administration
	File Management
	Login/Logout
	Your Profile

Other Wiki Sections

Software

Performance Optimization in MSMQ

{outline||||<1>. }

The following notes were taken from the Microsoft White Paper titled Optimizing Performance in a Microsoft Message Queue Server Environment, found here.

Put the sending and receiving apps on the same machine where possible.¶

This will allow operations such as moving or copying messages to occur faster at memory speeds rather than disk speeds.

Use Express Mode of message delivery.¶

This is faster than Recoverable Mode, but not recommended when failures cannot be tolerated or when a machine shutdown is possible when messages are in the queues.

If using Recoverable Mode, adjust the timeout value.¶

MSMQ won't write recoverable messages to disk when its queue manager can quickly confirm message delivery to the receiving app. The term "quickly" is defined by a short internal timeoue value, but I'm not sure if this timeout is even something that is configurable (i.e., whether it can be adjusted).

Use efficient dequeuing techniques, such as asynchronous notifications.¶

This will maximize the chance that queue depths stay close to zero. I speculate that this may also have an effect on the stability issues. In addition, performance can be improved by having a local receiving app remove messages quickly from their queues. This is because if the local receiving app is running and awaiting a message, MSMQ will copy the message directly into its incoming message buffer, thus avoiding the overhead of writing the message to a queue.

Use multiple message senders.¶

When there are multiple threads or applications sending messages to the same MSMQ on a machine, MSMQ 1.0 is able to batch disk-writing operations, thus minimizing disk delays.

Eliminate unnecessary MSMQ transactions.¶

Generally, applications that use transactions perform poorer than those that don't, so eliminate the use of transactions except where necessary.

Use internal MSMQ transactions where possible.¶

Internal transactions are faster than external (i.e., those coordinated by MS Distributed Transaction Coordinator). However, external transactions are required when if resources other than MSMQ need to be part of the transaction.

Increase the number of message operations per transaction where possible.¶

Because disk activity occurs only when the application attempts to commit a transaction, grouping messages into fewer transactions will improve performance.

Minimize locating and opening queues.¶

Because MSMQ must make an RPC when either locating or opening a public queue for reading or writing, applications should locate and open queues at startup instead of for each message.

Reduce or eliminate message authentication and encryption.¶

These operations are performance-costly.

Minimize message-body size.¶

Longer messages take more time and resources to process. Shortening the message body usually has the greatest effect.

Don't send SIDs with messages.¶

This will decrease the message-header size. To do this, the sending application should set the PROPID_M_SENDERID_TYPE property on the message equal to MQMSG_SENDERID_TYPE_NONE.

Minimize use of acknowledgment messages, because MSMQ treats them as any other message.¶

By default, MSMQ doesn't generate acknowledgements, but applications can request them by settngs the PROPID_M_ACKNOWLEDGE property on a message.

Minimize journaling of messages.¶

Messages can be journaled on both the sending machine (on a per-message basis) and on the receiving machine (on a per-queue basis). Since MSMQ always uses recoverable messages for journal operations, all performance guidelines for recoverable messages apply.

Increase RAM if necessary.¶

Since even recoverable messages are held in memory, the machine should have enough RAM to hold all the messages that are expected to accummulate in its queries. Otherwise, the system will be required to page RAM to disk.

Increase the number of hard disks.¶

Obviously, apps using recoverable messages will see the most improvement. Maximum performance is achieved using five separate disks - one for each of the following: (1) MSMQ message files, (2) MSMQ message log files, (3) MSMQ transaction log files, (4) Windows NT virtual memory paging files, (5) application data files. In addition, when the app uses MSDTC or MS SQL Server, configure their log files to use separate disks. If a five-disk configuration is impractical, note that a three-disk configuration will provide the most incremental performance boost.

Use higher performance disks.¶

Microsoft has measured a ten times better message throughput performance from a three-way hardwire-striped disk with a 2MB battery protected controller as opposed to a standard SCSI II disk.

Upgrade the operating system from Windows NT to Windows 2000.¶

Several performance improvements were introduced in Windows 2000, as follows.

• The number of I/O operations required to commit a transaction was significantly decreased.
• Receive operations were internally changed from synchronous to asynchronous, improving performance for multi-threaded applications.
• The batch-write mechanism was optimized.