Export (0) Print
Expand All

Handling Special Exchange Roles and Performance

 

Topic Last Modified: 2006-11-13

The previous sections listed the counters for the most common use of Exchange Servers—as mail-flow and mailbox servers. However, some organizations heavily use Exchange server roles, such as front-end servers and public folder servers. For those organizations, there are other performance issues that need to be monitored.

Front-end servers, such as those that serve Outlook Web Access, authentication, IP address checking, Secure Sockets Layer (SSL) protocol, and encryption schemes, have security features that require significant processing. For these servers, you are likely to see increased processor activity, both in privileged and user mode, and an increase in the rate of context switches and interrupts. If the processors in the server cannot handle this increased load, queues are likely to develop.

If your front-end servers are using SSL, the Local Security Authentication Server (Lsass.exe) process may consume a large amount of CPU. This is because SSL processing occurs here at the server. This means that administrators used to monitoring CPU usage may see less processor consumed by the Inetinfo.exe process and more consumed by the Lsass.exe process.

The following item describes how you can improve the front-end server performance:

  • Use hardware cryptographic accelerators

    When there is extremely high SSL use, you can improve performance by using hardware cryptographic accelerators to offload the calculations and remove SSL from being a bottleneck.

For public folder servers, it is important to understand that the replication traffic between public folders (if there is more than one public folder in the topology) can affect all the servers involved. Arrange the replication schedule of the servers so that a replication queue does not mount any public folder. Processing replication changes causes resource competition with the operations already occurring on the server.

Replication messages are received by SMTP, categorized and handed to the local SMTP queue. The messages are then submitted to the Public Folder store. Once they have been submitted to the Public Folder store the messages are put in the Replication Receive Queue. The messages in the Replication Receive Queue then get processed and the changes are performed on the appropriate Public Folder

Use the counter listed in the following table to determine whether there is any public folder performance degradation.

Performance Counter for Public Folder Server Receive Queue

Counter Expected values

MSExchangeIS Public\Replication Receive Queue Size

Indicates the number of replication messages waiting to be processed.

  • This value should not go above 100.

  • This value should return to a minimum value between replication intervals

The following item describes how you can improve the public folder server performance:

  • Tune replication schedule to avoid queues

    You can increase or decrease the frequency that a public folder replicates its content changes to other public folders. For some deployments, having replication contents replicate more frequently actually results in performance gains. These performance gains are possible because the increased replication frequency avoids big replication queues and involves less public folder content being replicated at a time.

    However, if replication is never completing then you will see an unbounded growth of the Replication Receive Queue size. When changing the frequency of replication monitor this counter to ensure that replication is completing before the beginning of the next interval.

  • Minimize the number of replicas

    Minimizing the number of replicas will also result in performance gains. In some cases multiple replicas of folders may have been added in order to distribute the load over multiple servers. A more effective way to balance the load would be to divide the folders across multiple servers.

    For example, if you were to divide the folders between two servers such that each server had replicas of half the hierarchy that scenario would result in less load per server than if the two servers that had replicas of all the folders. Dividing the folders results in better performance because there will not be the added performance cost of replicating all the content changes between the servers.

  • Throttling Offline Address Book downloads to reduce network hit

    Exchange 2003 and Outlook 2003 Cached Mode increase the number of downloads of the Offline Address Book (OAB). These downloads may result in very high network utilization and may overload the network. By default, every client request for a full OAB is served immediately. Throttling the OAB downloads will help limit the effect on the network. See the following Microsoft Knowledge Base articles for more information.

  • Structuring the Public Folder hierarchy

    Reducing the number of direct subfolders will also help improve performance. A deeper and narrow hierarchy will have lower performance cost than a shallow and wide hierarchy. Limiting the number of direct subfolders for any given folder to 250 will reduce the cost of both replication and user actions.

  • Limiting the number of messages per folder

    Limiting the number of messages for a public folder will reduce search and sort times on that folder. This will improve the client experience as well as reduce load on the server.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft