Long-running MAPI operation
[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at http://go.microsoft.com/fwlink/?linkid=34707.]
Topic Last Modified: 2006-11-22
The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.
If the Exchange Server Analyzer determines that a user has had one or more MAPI operations take longer than 30 seconds, the Exchange Server Analyzer displays an error.
An increase in the number of views for each folder can add overhead to many MAPI operations. Two the most common, SeekRow and FindRow, are discussed in this topic. Other MAPI operations identified by the Exchange Server Analyzer as 'long running' can usually be resolved by the same actions as the SeekRow and FindRow MAPI operations.
Client applications use the MAPI operations SeekRow or FindRow to move the pointer between rows in a view. SeekRow specifies how many rows to move the pointer, and is very low-cost with regard to CPU time. FindRow is very expensive because it moves the pointer to the first item in a non-materialized (will not be cached) view that matches the restriction criteria, and then discards the view after the client application is finished with the action. The ultimate CPU cost of FindRow depends on the complexity of the restriction, the number of message properties that are accessed for each message, and how many rows the store has to review before finding the first item that matches the criteria and so is loosely correlated with the number of items in the folder.
MAPI operations taking longer than 30 seconds may not always be a problem. If the identified user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, you should understand why. Work with the user experiencing the high latency to determine:
If the item counts in folders are high.
What applications the user is running.
To address this issue:
Encourage users who have many items in their folders to reduce the number of items per folder. We recommend that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders under 5,000
Configure the most operationally expensive client computers (especially those with long latencies on Restrict, SetColumns or FindRow operations) to use Cached Exchange Mode. Cached Exchange Mode isolates the server from most of the excess RPC traffic.
Try turning off all the applications and then turn them on one by one to find which one might be causing the problem. If these applications are not required for business, or if the applications have a published hot fix, permanently turn off the applications or update them to reduce the load to an appropriate level.
Some applications can significantly increase server load without issuing lots of MAPI operations. This is because some operations are more expensive than others. It may take only a small increase in the number of costly operations to noticeably affect server performance. In ExMon, these users are reported as having a high CPU effect, without necessarily having issued lots of MAPI operations.
Also be aware that when there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies for the MAPI operations will increase. Determine server resource bottlenecks and either increase server resource capacity or move users to less-loaded server.
For More Information
For more information, see the following Exchange Server resources:
Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)
Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588)
Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)
Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)