IMPORTANT: This article provides guidance for Exchange 2003. For guidance on more recent versions of the Exchange product, please see the following resources:
Many times I've been asked to give a guideline on how large a mailbox can be before performance degrades, or on the recommended size for a mailbox. Unfortunately, this question is like asking "How many cookies are enough?" There may be a lot of implied information, but the question itself is vague. For example, I personally think there are never enough cookies, while my brother won’t eat more than one. Nonetheless, I have been asked to forge ahead, declaring my assumptions, and stating my conclusions.
First, there are no inherent size limits on individual mailboxes. The main factors that limit mailbox size, practically speaking, are available disk space, backup and restore times, Service Level Agreements, and Outlook performance. By Outlook performance I’m referring to the latencies experienced by the end user. In this blog, I'll just talk about the limitation due to Outlook performance.
It's item count, not size, that matters
First, it's not the size of the mailbox that impacts performance - it is the number of items in the folder or folders that are being accessed on the server. In particular, performance is largely influenced by the number of items in the most commonly used folders: Calendar, Contacts, Inbox, and Sent Item folder.
Having a large number of items in a folder will mean than operations in that folder will take longer. Operations that depend on the number of items in the folder include adding a new column to the view, sorting on a new column, finds and searches. Many Outlook plug-ins do sorts or searches as they are running, and these requests may overlap with other Outlook MAPI requests, resulting in a poor user experience.
If you are running in Cached-Mode, (the default mode for Outlook 2003), then client performance can be an issue. One thing you should do is keep your OST files (the local data cache) free of fragments. There is a nice little tool called CONTIG on sysinternals.com for this purpose (http://www.sysinternals.com/ntw2k/freeware/contig.shtml).
All user pain is subjective
Setting a limit depends somewhat on your users’ tolerance for pain. Are they comfortable with slow Outlook operations, or do they expect a snappy response? How much wait are your users willing to tolerate? The number of items in these key folders has a large impact on the delays for many common actions, and this is one factor that the user can control. Publishing guidelines for your users may help them control their own experience.
Not all users are created equal
In addition to the number of items in the key folders, there are other factors that impact the Outlook experience, such as the number of other MAPI applications or Outlook plug-ins running on the user’s machine. All MAPI requests contend for attention in emsmdb32.dll; if you have a lot of plug-ins making requests, Outlook will run slower. Furthermore, the complexity of the action will have an impact. For example, marking all items in a folder as read is going to take a lot longer than marking one item. Other actions that inherently may take a long time include getting free-busy information for a lot of users on a meeting request, or doing a search across multiple folders. If your users are frequently doing complex actions, have lots of plug-ins, or have high use of the contacts and calendar folder, you may want to recommend that they keep limit the number of items in their critical path folders.
Not all servers are created equal
If you're running on really old hardware, you may experience poor performance at a lower number of items than if you're running on the latest-and-greatest. This is a big area and I’m just not going to go into this any further here... Ok, I lied; I have to add one more thing: disk latencies. For optimal user experience, make sure disk latencies are small (eg, 20ms or less), even during peak server usage (see my earlier disk blogs).
Here’s an example to show how disk latency can add up. When getting a view, the requests for the data are done in individual, serialized requests from the disk, not bulk operations. So for example, if a plug-in is getting a view of 1000 items, then the Exchange store will probably make about 200 separate requests for data (assuming about 5 messages are retrieved per request). At 20 ms, that’s a guaranteed 4 second delay just from the disk subsystem alone! Imagine if your disk latency was 50ms or 100ms? To make matters worse, if you have multiple plug-ins making similar requests, you may find that your Outlook client is frequently blocked. Help yourself (and the other users) by keeping disk I/O latency low.
The Bottom Line:
I usually recommend no more than about 2500 - 5000 messages in any of the critical path folders. The critical path folders are the Calendar, Contacts, Inbox, and Sent Item folder. Ideally, keep the Inbox, Contacts and Calendar to 1000 or less. Other folders, particularly custom folders created by the user, can handle having larger numbers of items without having a broad impact on the user experience (20,000 items in my "Cookie Recipes" folder? No problem - except when I need to find that recipe from last Christmas!).
If getting word out to the users to reduce folder item counts is impractical, administrators have another option. Administrators can use the Mailbox Manager tool to control the size of critical mailbox folders. Unfortunately, Mailbox Manager does not evaluate the mailboxes based on message count within a folder— instead it processes messages by age and/or size of message. Regardless, if your organization allows the use of it, it can help prevent mail folders - and user-frustration - from getting out of control.
- Nicole Allen
