Identifying Slow RPC Request Processing

 

When using Microsoft® Office Outlook® in MAPI mode, clients actions in Outlook translate to remote procedure calls (RPCs) between the clients and the server. If the user is running in online mode, these RPC calls occur synchronously. Any delay by the server in fulfilling these synchronous requests directly affects user experience and the responsiveness of Outlook. Conversely, running in cached mode results in the majority of these requests being handled asynchronously. Asynchronous processing means that the speed at which most user actions are initiated should not translate into the responsiveness or overall experience of Outlook.

Generally, spikes in RPC requests that do not increase RPC operations/sec indicate that there are bottlenecks preventing the store from fulfilling the requests in a timely manner. It is relatively simple to identify where the bottlenecks are occurring with regards to RPC requests and RPC operations/sec. If the client experiences delays, but the RPC requests are zero and the RPC operations/sec are low, the performance problem is happening before Exchange processes the requests (that is, before the Microsoft Exchange Information Store service actually gets the incoming requests). All other combinations point to a problem either while Exchange processes the requests or after Exchange processes those requests.

The counters shown in the following table indicate delays in fulfilling RPC requests.

Performance Counters for RPC Processing

Counter	Expectations
MSExchangeIS\RPC Requests Indicates the number of MAPI RPC requests presently being serviced by the Microsoft Exchange Information Store service. The Microsoft Exchange Information Store service can service only 100 RPC requests (the default maximum value, unless configured otherwise) simultaneously before rejecting client requests.	It should be below 30 at all times.
MSExchangeIS\RPC Averaged Latency Indicates the RPC latency in milliseconds, averaged for the past 1024 packets.	It should be below 50 ms at all times.

Client-Side Monitoring

Microsoft Office Outlook 2003 includes added client-side monitoring features. Client-side monitoring is used to find client errors and latency problems. You can enable client-side monitoring on an Exchange Server by modifying the server's registry. When enabled, Outlook 2003 clients send data to the server based on status and state of connection, which includes failed RPC requests and error conditions. This information is aggregated on the server and logged in event log entries on the server. For detailed steps on how to enable client-side monitoring in Outlook 2003, see How to Enable Client-Side Monitoring for Outlook 2003.

Example of Monitoring RPC Processing

In this example, the server is CPU-bound and the processors cannot handle the incoming RPC requests in a timely manner. This means that the RPC requests accumulate and have a high latency. This is shown in the following figure where the MSExchangeIS\RPC Requests counter is constantly averaging 90 and the MSExchangeIS\RPC Averaged Latency counter is approximately 146 milliseconds (ms).

Monitoring RPC processing using the Performance snap-in