Freigeben über

Best Practices for Administering Message Queuing

  • Artikel

Applies To: Windows Server 2008

This topic lists best practices for administering Message Queuing in the Microsoft Windows 7 and Windows Server 2008 R2 operating systems.

The following best practices should be followed when administering Message Queuing:

Planning and deployment recommendations

Avoid deploying dependent clients

Because of several limitations with using dependent clients, we recommend that you deploy independent clients rather than dependent clients wherever practical. If you must use dependent clients, the supporting Message Queuing server should be located in the same site as the dependent client. This will improve messaging performance for the dependent client.

For more information about dependent clients see Dependent Clients.

Install Message Queuing servers in every Message Queuing site

You should install at least one Message Queuing server with routing enabled in every Message Queuing site in your Active Directory Domain Services forest. This is to ensure that messages are able to reach their destination between sites.

For more information about Message Queuing Routing see Message Queuing Routing.

Do not manually create Message Queuing objects in Active Directory Domain Services before you install or upgrade Message Queuing

Installing or upgrading Message Queuing in domain mode creates Message Queuing objects automatically in Active Directory Domain Services. If you have manually created objects, for example the msmq queue object, before the installation or upgrade, the automatic creation of the MSMQ objects may be impaired and will not function as expected.

For more information Message Queuing and Active Directory Domain Services see Message Queuing and Active Directory Domain Services.

Consider performance requirements for your Message Queuing deployment

Review the Planning Overview and Message Queuing Message and Data Files topics to better assess the performance requirements for your Message Queuing deployment.

Administering messages and queues

Do not store more express messages than physical RAM can hold

To minimize paging on your computer and thereby increase messaging performance, do not store more express messages than physical RAM can hold.

For more information about Express messaging, see Message Delivery Methods.

Take message overhead into account

The minimum overhead for sending a message on the network is approximately 150 bytes, which includes a signature, source and target computer IDs, a target queue name, and message properties. The overhead increases if you use transactions, a multiple queue format name, or authentication. For example, for authentication and encryption, the following overhead applies:

  • An internal certificate is approximately 400 bytes.

  • An external certificate is at least 1 kilobyte.

  • A symmetric key is 76 bytes (for 40-bit encryption).

  • Security ID (SID) is tens of bytes.

Put a policy in place for emptying queues

Unread messages take up disk space. As more messages fill up the disk, performance will slow down. Consider the following strategies:

  • Periodically clean up journal and dead-letter queues.

  • Use the MSMQ Service\Total Bytes in All Queues performance counter to monitor queue disk space.

Note that MSMQ stores messages in 4-megabyte memory-mapped files. As additional message storage space is needed, additional files are created and mapped into the MSMQ memory space. By default, MSMQ will delete and unmap empty message files every 6 hours, but the files are not defragmented. As a result, a message file may contain a single 1-kilobyte message, yet consume 4-megabytes of storage. For this reason, purging queues may not reduce the MSMQ working set.

Do not use journaling unless needed

Journaling can use up disk space quickly. If you must use journaling, to increase messaging performance, purge messages in all journal queues and dead-letter queues often.

For more information about journaling see Journals and Administering Journals for Message Queuing.

Administering the Message Queuing service

Do not stop the Message Queuing service

Do not stop the Message Queuing service on a computer unless absolutely necessary. Otherwise, all express messages will be lost. For more information about possible message loss when using express messaging see Message Delivery Methods.

Avoid changing the Message Queuing service account

The Message Queuing service runs under the Network Service account by default. Do not change the account that the Message Queuing service runs as unless absolutely necessary. Running the service as other users may grant additional permissions to the service which may compromise the security of the system.

Do not use journaling unless needed

Journaling can use up disk space quickly. If you must use journaling, to increase messaging performance, purge messages in all journal queues and dead-letter queues often.

For more information about journaling see Journals

Administering message routing

Do not install a Message Queuing server with routing on a domain controller

If your Message Queuing infrastructure requires both message routing and Active Directory Domain Services access, install this functionality on different computers to prevent overload on the domain controller. For example, install a Message Queuing server with routing enabled on a non-domain controller computer, and install another Message Queuing server on a Windows Server 2008 domain controller to provide Active Directory Domain Services access for Windows 2000 clients. This configuration helps prevent overload on the domain controller.

Note

The Windows 2000 Client Support feature has been removed from Message Queuing 5.0. To support message queuing on Windows 2000 down-level clients, at least one Windows Server 2003 or Windows Server 2008 domain controller with Windows 2000 Client Support feature must be configured in the domain.

Use routing links to connect all sites

Routing links establish a means to route Message Queuing messages between sites, and there should be sufficient routing links to connect all sites, though these links do not have to be direct. Site gates, which are optional unless you are using MSMQ-MQSeries Bridge, act as a gateway between different sites. A routing link should be created for every new Windows Server 2008 R2 site that is created.

For more information about Message Queuing Routing see Message Queuing Routing.

Configure in-routing and out-routing servers for mobile clients

It is recommended that in-routing and out-routing servers be available for mobile clients that are mostly disconnected from the network or connect to the network through a remote access server.