Topic Last Modified: 2008-04-24

The Microsoft® Exchange Server Analyzer Tool has determined that your server is not operating at optimal performance. The Exchange Server Analyzer evaluates many remote procedure call (RPC) performance counters. If the reported data in the RPC performance counters do not compare favorably to the levels in the table below, a warning is displayed.

Number of Users on the Exchange Server RPC Averaged Latency Threshold

Less than 500

Average greater than 15

Greater than or equal to 500 but less than 3000

Average greater than 30

Greater than 3000

Average greater than 50

The following performance counters are discussed in this article and are managed by the MSExchangeIS performance object:

RPC Averaged Latency

The RPC Averaged Latency performance counter records the average time, in milliseconds (ms), that it takes for the last 1024 packets to be processed. The latency represents how long it takes from the time the Store.exe process received the packet to the time it returned the packet. The RPC Averaged Latency performance counter does not include any network latency or any latency that is introduced by anything other than the Store.exe process. Although the RPC Averaged Latency performance counter data does not include network transit time, it does provide data about the shortest time period that client computers have waited for a response from the server. If the RPC Averaged Latency performance counter data is lower than 50 ms, the server can process the requests in a reasonable amount of time. If the counter stays greater than 50 ms for more than several seconds, this indicates that the server is having difficulty keeping up with the load. As a result, users may experience delays when accessing their e-mail. If average latency is greater than 100 ms, users will receive the following pop-up window from their Microsoft Office Outlook® client computers: "Retrieving data from Exchange Server."

Interpreting the RPC Averaged Latency Performance Counter

The RPC Averaged Latency counter can be misleading in the following two situations:

  • First, some MAPI operations are expected to take a long time. For example, if the client computer searches a folder that contains thousands of items in an attempt locate all items that match complex criteria, it is ordinary for such an operation to take several seconds. If there are few users on the server, this ongoing operation may cause a spike in the RPC Average Latency. If the RPC load on the server is low, observe the average for this value over a longer period of time (at least several minutes), instead of acting upon the short-term, more volatile behavior.

  • The second situation that may occur is when the RPC load on the server is very low. Sometimes, depending on the activity of the busiest user, the latency can change dramatically. Because the server load is particularly stressed, the result of heavy operation by a single user may unintentionally skew the RPC average latency data.

RPC Requests

The RPC Requests performance counter records the number of client computer requests that are currently being processed by Exchange. The counter has a maximum value of 100. After the Exchange store has 100 RPC operations being processed, it regularly refuses any new connections. On a healthy server, the number of outstanding requests should be lower than 50. If the number is greater than 50 for a long time, this indicates that RPCs are backed up and waiting to be processed and client computers are probably experiencing delays.

Interpreting RPC Requests

The threshold of 50 requests is not a strict threshold. A lightly loaded server may start to have performance problems before the counter reaches 30; however, a heavily loaded server may function correctly at 50 requests. Ideally, for each server, a baseline value for this counter should be measured. The Exchange Server Performance Troubleshooting Analyzer uses the threshold of 50, which is appropriate for most large servers.

Compared to a heavily loaded server, a lightly loaded server has a reduced value for RPC requests. This is because a lightly loaded server requires fewer threads to keep pace with the load. To avoid falling behind and to obtain a greater RPC request value, a busier server must perform more concurrent work. Therefore, on a heavily loaded server, the greater RPC request value does not, on its own, imply a performance problem. To assess the "slowness" of the server, you must also consider the RPC Average Latency performance counter.

Causes of Latency

An increase in latency may be caused by the following:

  • An increase in RPC load

  • A bottleneck in one or more server resources

Furthermore, a bottleneck may be caused by the following:

  • High RPC load (or any other load on the server)

  • Hardware malfunction or configuration error

To correct this error