Planning Overview

  • Article

Applies To: Windows Server 2008, Windows Vista

When planning a Message Queuing deployment, it is important to consider performance requirements. After you have assessed these requirements, you can make informed decisions about your hardware requirements and upgrading strategies. Generally, performance of Message Queuing applications, like other applications, can be improved with the following strategies:

  • Increasing the amount of system memory for each server.

  • Upgrading the processor or adding additional processors.

  • Increasing the number, speed, or size of the disks.

  • Replacing disk drives and volume sets with striped drive arrays.

  • Limiting the number of other services running on the computer by moving nonessential software to other computers. A server that runs additional services needs greater hardware resources than it would otherwise.

Disk considerations

Consider the following:

  • Number of disks. Since family operating systems and Message Queuing are able to perform many disk operations in parallel, using separate physical disks (as opposed to single disks with multiple partitions) will result in performance improvements for most Message Queuing applications. Applications that use recoverable or transactional messages will see the greatest improvement because these messages are constantly being written to disk and retrieved from disk.

  • Disk type. Not all hard disks deliver equivalent performance. In particular, there are high-performance disks that use hardware striping and battery-protected write-through disk controllers that delay write operations until they can be performed most efficiently. These disks will significantly improve messaging performance, especially when sending or receiving recoverable or transactional messages. Note also that for the best messaging performance on Message Queuing servers, put the messaging (*.mq) files, message log files, and transaction log files on separate physical disks.

  • Disk size. When deciding disk size for your computers, consider the space requirements for Message Queuing files, the type of messaging (recoverable, transactional or express), the total number of messages that are likely to accumulate on the server at any time, and the total size of those messages. It can be difficult to anticipate message storage requirements. However, if you use Message Queuing servers for session concentration within a site (in-routing and out-routing servers) or in routing links (site gates), you must allow for additional message storage space on those servers. Also, servers that support dependent clients are likely to need additional disk space.

  • Number of disk drives. Adding disk drives ensures that disk access has a minimal impact on messaging performance. However, if your CPU (processor) usage is at or near 100%, adding disk drives does not improve messaging performance. To determine whether your computers are limited by disk access or by processing power, use System Monitor to track the % Processor Time counter (located in the Processor object) and the Avg. Disk Queue Length counter (located in the DiskLength object). If the sustained % Processor Time value is above 75% during the time messages are being sent, adding processing capacity may improve messaging performance. If the Avg. Disk Queue Length value for any drive is greater than 0.6 when messages are being sent, additional disks may improve messaging performance.

For more information about monitoring Message Queuing performance, see Monitoring and Testing Message Queuing [LH]. For information about the message and data files used by Message Queuing see Message Queuing Message and Data Files.

Memory considerations

Consider the following:

  • Storing messages. To maximize messaging performance, there must be enough memory on a given computer to hold all of the messages that are expected to accumulate in its queues under normal operation. Messages may accumulate on the source computers, if destination computers are unreachable. On destination computers, messages will accumulate if receiving applications are not running, or are unable to keep up with the arrival rate of messages.

  • Calculating RAM requirements. To calculate the amount of RAM required to hold all messages, you must consider message sizes. For example, when sending 20,000 messages that are approximately 1 kilobytes (KB) each with typical header sizes, allow at least 23 megabytes (MB) (20,000 × 1 KB + 20,000 × 150) of available RAM beyond normal system requirements. Note that this applies only to cases where all messages actually accumulate on a computer. If messages are normally retrieved (removed from queues) as quickly as they are delivered, significantly less RAM will be required.

Rolling out Message Queuing

A rollout process can consist of the following phases:

  • Setting administrative policy. When setting out such a policy, consider how access control will be established in your organization, how administrative duties will be delegated, how work will be documented, and how backups and emergencies will be handled.

  • Conducting lab tests. Lab testing helps you to determine the load that Message Queuing places on your servers, and tests your in-house Message Queuing applications. Before conducting such tests, ensure that your computers meet the minimum hardware requirements for running Message Queuing, and that your Message Queuing applications are functioning properly.

  • Conducting one or more pilot rollouts. After Message Queuing has been tested in a lab, you can deploy in a limited environment. It is recommended that the pilot rollout be introduced on a limited scale, such as 15 to 50 users. You can then make any needed adjustments to your administrative policy and to your Message Queuing applications for the final rollout. If you make extensive changes to the final rollout plan, consider doing a second pilot rollout.

  • Conducting the final rollout. After analyzing the results of the pilot rollouts, you are ready to finalize the plans for the full-scale rollout of Message Queuing in your organization. The final rollout plan is an extension of the pilot planning process, with the added steps of documenting, budgeting for, and carrying out the final logistics.