With the release of Exchange 2013 SP1, it’s time to revise our sizing guidance given feedback from customers, observations from our own large-scale deployments, and requirements associated with new and changed components in SP1. In addition to this brief article, I’ve also updated the original blog post with updated formulas and tables to reflect the changes described here.
There are two specific changes that need to be highlighted:
With the introduction of the MAPI/HTTP protocol, our existing sizing guidance for CAS processor utilization needs to be changed. Usage of MAPI/HTTP has a fairly dramatic increase in rate of requests handled by the CAS role, when compared to requests generated by clients using RPC/HTTP. As each connection has a measurable amount of processing overhead, this results in an overall increase to our CPU requirements on CAS, moving from a 1:4 ratio of CAS to Mailbox processor cores, to a 3:8 ratio (a 50% increase). It’s important to call out that MAPI/HTTP is disabled by default, as we expect that customers will want to carefully evaluate the deployment requirements and impact of MAPI/HTTP before enabling it. Because it is disabled by default, existing Exchange 2013 deployments do not need to immediately add more CPU resources at the CAS layer. Instead, we expect that additional capacity will be considered as part of the evaluation and deployment process for MAPI/HTTP. We do anticipate that over time it will become the standard method of connectivity for Outlook clients so it’s important to include these requirements in our sizing guidance as early as possible.
It’s also critical to deploy .NET Framework 4.5.1 if you intend to use MAPI/HTTP, as it contains an important fix that impacts the performance and scalability of MAPI/HTTP at the CAS layer.
Ross has updated the Exchange Server 2013 Server Role Requirements Calculator to take into account this guidance change in version 6.3.
As memory requirements have increased for Exchange, our historical guidance for sizing the pagefile has become more and more challenging from a deployment perspective. Previously, our guidance was to set a fixed pagefile size equal to the size of RAM + 10MB. On servers that are commonly deployed with 128GB of RAM or more, requiring a pagefile sized to RAM+10MB results in a large amount of space consumed (typically on the system drive) with questionable benefit. In our large-scale internal deployments, we have been running with a cap on pagefile size for quite some time, and as a result we are comfortable recommending that all of our on-premises customers follow that same guidance. Moving forward with Exchange 2013, we recommend a fixed pagefile of the smaller of RAM size + 10MB or 32,778 MB (which is 32GB + 10MB). Hopefully this will free up some needed space on your servers.
As we continue to learn more from customer feedback and monitoring of our own deployments, we will keep updating this guidance via posts to the blog.
Jeff Mealiffe Principal Program Manager Lead Exchange Customer Experience