IMAP4 and Exchange 2010 RTM

Published May 06 2010 05:53 PM 2,402 Views

I'd like to take the time to highlight the significant improvements in the performance of the Internet Message Access Protocol 4 (IMAP4) in Exchange 2010, and also emphasize the importance of knowing the mailbox size when sizing your Client Access Servers for IMAP4 users. These results, and more details, will be included in an upcoming CAS Guidance whitepaper that will be posted on TechNet.

Comparison with Exchange 2007

Exchange 2010 reduces the total CAS CPU/user by 40% while reducing the memory footprint by 30%. These results were obtained with 100 MB mailboxes filled MAPI-format messages, typical of enterprise environments dominated by Outlook users.  Not reflected in these results are the improvements we made to further reduce our CPU costs with non-MAPI (MIME) messages.

In the comparison below, users are doing the same set of actions, but the E14 system was able to respond more quickly to requests so the number of concurrent connections dropped even while the fetch rate increased.  We used IMAP4 fetch commands to normalize our results - the 'fetch' represents a unit of work which includes, for example, a portion of logon and logoff actions.  The results here are for a stand-alone CAS server (with 2-duel core Xeon Processors at 2.33GHz) in a multi machine topology.

IMAP4 costs and Mailbox Size

IMAP load typically depends on the size of the user's mailbox, since many clients, including Outlook Express, retrieve the headers from the entire folder when opening it. Comparing 2MB with 100 MB and 220MB mailboxes we saw CPU cost/user change dramatically as the mailbox size increased.

Our Client Access Server was a 2007 CPU design (2 L5335 Xeon 4-core processors @2 GHz) running on Windows 2008 R2 with 16 GB of RAM. It was supported by: two servers running the Mailbox role, with 16 databases per server; a Hub Transport server; and an Active Directory server.

Users were simulated from 10 client machines, running Exchange Load Generator 2010, using the IMAP module and a script that simulated Outlook Express connecting with IMAP (the script will be included in the upcoming whitepaper). Since IMAP4 users generally use the Simple Mail Transfer Protocol (SMTP) to send mail, which doesn't impact the Client Access Server, no messages were sent or delivered during these tests.

The CPU cost per IMAP4 user increased with the number of users for all three mailbox sizes, and increased much more dramatically as the size of the mailbox grew.

Projecting the limits of concurrent IMAP users resulting in 12 GHz of CAS CPU consumed (75% total CPU on this server) shows a factor of 10 drop going from 2 MB to 100 MB, and another factor of 2 between 100 MB and 220 MB. (I used a linear fit for the larger mailboxes since the number of users never gets large enough for the higher order term to dominate.) Clearly knowing the average Mailbox size will play a vital role in planning for IMAP4 CAS capacity.

To convert to total IMAP4 users supported per day consider a '100 Profile' (Heavy) user who receives 80 messages/day, or, on average, 0.00278 messages/sec in an 8 hour workday, and note that an IMAP4 fetch must be done for each message read. To get the Daily IMAP4 Users value we divide the MSExchangeIMAP4\Fetch Rate by (messages received/sec)/Heavy User, and then finally divide by two as a typical 'peak load' factor. The same data as above, but plotted verses the 'Daily IMAP4 Users' yields about 62,000 daily IMAP4 Users. Be sure to do your own calculations and validations before putting servers into production, as your profile and 'peak load' factor will most likely be different.

The larger mailboxes resulted in an expected increase in the RPC operations/user, to retrieve the extra data, which increased the costs on the MBX server, in this case the RPC operations/user and the MHz/user both doubled (the MBX MHz point for 125 users with 100 MB mailboxes is not plotted as it was unreliable). The number of LDAP searches/user, and thus AD costs, also increased due to increased recipient resolution. DO NOT use these values for Mailbox or Active Directory Sizing without considering delivery costs, as there were NO deliveries happening during these measurements.

Clearly knowing the Mailbox size will play a vital role in planning for IMAP4 capacity.

- Greg Smith

Not applicable
I would be interested to know what percentage of customer experience participants have IMAP usage.  I realize that in some verticals it is in high use/demand, but I have yet to be presented with a design challenge for IMAP usage.
Not applicable
It is very strange article. Why compare E10 with E7SP1? Does E7SP1 support W2K8R2? You take for testing old processor L5335. It would be intresting how to E7SP2 IMAP services work on new Intel processsors 56xx series.
Not applicable
If I understand correctly, it's not really the mailbox size that causes more CPU usage but the number of items in the folder, right?

Also, why would the number of LDAP operations per second grow with the mailbox size or am I reading this wrong.
Not applicable
people use imap?
Not applicable
Are people really still using IMAP over all the other great technoligies in Exch 2010 ?  I also do not see a need for IMAP.
Not applicable
As my name shows, I think IMAP sucks.  However, what do YOU use to connect your Linux and MAC clients?  Evolution is sorely lacking, as is Entourage and MAC Mail.  "Light" OWA is horrible, so E10 will allow some improvement by allowing Safari and Firefox to connect, but there's still no local download for offline use.  So - without IMAP, what do YOU do?  Not all of us are blessed to work in a Windows / Outlook only environment.
Not applicable
I realize the mailbox sizes of 100 and 200MB are to show how E14 scales, but it's hardly a realistic mailbox size in 2010.  Our users have attachments larger than that.  Is 100MB of mail really typical of an enterprise environment? Old school thinking like this makes IT directors push for GMAIL (20GB+ MBs).  Can you give us real world results for a 5GB mailbox?
Version history
Last update:
‎May 06 2010 05:53 PM
Updated by: