Exchange Public Folder Best Practices: Scalability
When you design and implement your deployment of Microsoft® Exchange Server public folders, consider the following factors as you determine how to optimize scalability:
Number of public folder databases
Public folder hierarchy width and depth
Items per public folder
Users per public folder database
This article discusses each of these factors in detail. For more information about disk size, public folder growth rates, and general capacity planning, see Exchange Public Folder Best Practices: Managing Data.
Number of Public Folder Databases
When you plan how many public folder databases to deploy, consider these two best practices.
First, for large enterprise topologies where public folders are heavily used, deploy dedicated public folder servers. This best practice stems from the general best practice of dedicating CPU resources and disk resources to isolated server functions.
Second, remember that a few large public folder databases scale better and are more easily managed than many smaller public folder databases. By reducing the number of public folder databases, you can decrease the time that is required to back up and restore many smaller databases. You also reduce the amount of background replication traffic. Additionally, online maintenance of fewer larger databases is quicker than online maintenance of many smaller databases. Finally, it is easier to manage a smaller number of public folder databases from the perspective of applying permissions and content access, and implementing efficient replication and referrals.
The best practice that a few large public folder databases scale better and are more easily managed than many smaller public folder databases is especially true when you consider your topology from the organization level. From the server level, some management and maintenance tasks, such as backup and restore, are more quickly performed when more, smaller databases are deployed. Ultimately, the number of public folder databases that you deploy must address your business requirements. As you determine the number of databases that you want to deploy, you must balance the cost of replication traffic against the costs of database backup, maintenance, and restore times.
Hierarchy Width and Depth
As you design your public folder hierarchy, you must recognize the effect of hierarchy replication in your environment. Deep public folder hierarchies scale better than wide hierarchies. A deep hierarchy consists of many vertically nested folders, instead of many higher-level folders. A wide hierarchy consists of many higher-level folders with fewer vertically nested subfolders.
For example, consider how 250 folders might be arranged in a specific hierarchy. A wide hierarchy might have 250 direct subfolders under one parent folder. A deep hierarchy might have five top level folders, each with five direct subfolders. Inside each of those subfolders may be ten subfolders.
In both these examples, there are 250 folders (5*5*10=250). However, the deep hierarchy offers better performance than the wide hierarchy for two reasons. The first reason is because of the way that replication handles folders that have different permissions applied to them. The second reason is that client actions, such as sort, search, and expand, against a folder that has ten subfolders is much less expensive than a folder that has 250 subfolders.
While deep hierarchies scale better than wide hierarchies, remember that it is best practice not to exceed 250 subfolders per folder. Exceeding 250 subfolders likely will cause an unacceptable client experience when a client requests access.
As mentioned earlier, a factor to consider as you implement a hierarchy is the effect that permissions have on a client experience when a user wants to gain access to public folders. When each public folder subfolder has its own Access Control List (ACL) entries defined, every time that the Exchange Server computer receives a new public folder replication message, the ACL for the parent public folder must be evaluated to determine which users have rights to see the changes to the parent public folder. If the parent public folder has a large discretionary access control list (DACL) entry, it may take a long time to update the view for each public folder subscriber.
Note
The DACL for the parent folder is made up of the sum of the DACLs of all the public folder subfolders.
You may have many megabytes (MB) of DACL data that must be parsed if the following conditions are true:
You have many subfolders under a single parent public folder.
Each of those subfolders has its own ACL defined.
This DACL data must be parsed so that the display can be updated for all the public folder subscribers every time that a public folder replication message is received.
Therefore, it is recommended that you arrange your public folder hierarchy according to the user sets that gain access to the parent folders. Additionally, do not implement complex permission models on your public folder hierarchies. If you have already implemented deep folder hierarchies with different permissions at various nodes of the tree, see the Microsoft Knowledge Base article, "Users experience a slow response when they access public folders on a computer that is running Exchange Server 2003" for a hotfix that may improve client performance. For a similar hotfix for Exchange 2000 Server, see the Knowledge Base article, "Users experience a slow response from an Exchange 2000 Server public folder server."
When you consider hierarchy design, you should also consider how you will replicate the content in the hierarchy. Most of the time, it makes sense to distribute the content and reduce the number of replicas as much as you can. For more information, see Exchange Public Folder Best Practices: Implementing Replication.
Items per Folder
As a best practice, the number of items per public folder should not exceed 5,000 items. To manage the number of items per folder, you should configure expiration accordingly. If the 5,000 item per folder limit is reached regularly, even with an aggressive expiration schedule, consider segmenting the public folder subject into sub-topics and creating multiple public folders for each sub-topic.
For more information, see Exchange Public Folder Best Practices: Managing Data.
Users per Public Folder Database
Although there are no set limits on the number of users who can gain access to a single public folder database, it is recommended that you limit users to 10,000 users. The main reason for this recommended limit is that Exchange Server may run out of virtual memory or kernel memory when more than 10,000 users gain access to a single database.
You should monitor Client Logons and Peak Client Logons in the MSExchangeIS Public performance object of the Performance Microsoft Management Console (MMC) snap-in administrative tool to track the number of users who gain access to the public folders on a specific server.
For more information about monitoring load, performance tuning, and scalability, see the Exchange Server 2003 Performance and Scalability Guide.
For More Information
To learn more about public folders in Exchange Server, see the following resources: