Best Practices for Publishing Portals

Office SharePoint Server 2007 performs best with n+1 front-end Web servers, where n is the number of front-end Web servers that you determined through capacity planning. Running n+1 servers enables you to pull one server out of network load balancing, and recycle it without affecting service availability. You should plan for three Web servers at a minimum. For more information, see Plan for redundancy (Office SharePoint Server).

Web Parts that query lists can be very resource-intensive. Understand the scope of each operation that a Web Part that rolls up data performs.

When using query-driven Web Parts such as the Content Query Web Part, do the following:

• Select from as few lists as possible. Select from only the lists that you must.

• Index the columns that are first in the Content Query Web Parts. For more information, see the section Content Query Web Part in Additional performance and capacity planning factors (Office SharePoint Server).

• To query large amounts of data that is distributed across different sites or site collections, use SharePoint Search. It is much more efficient at these types of queries than the SPQuery object.

• Be sure that queries follow the guidance about large lists in the following articles:

  • White paper: Working with large lists in Office SharePoint Server 2007

  • The section "Manage your large lists for performance" in Downloadable book: Planning and Deploying Service Pack 1 for Microsoft Office SharePoint Server 2007 in a Multi-server Environment (http://go.microsoft.com/fwlink/?LinkId=125982).

Follow the recommended limits for lists and databases to optimize query performance. Exceeding list and database limits directly affects the performance of Office SharePoint Server 2007 features and behavior. For information about specific limits, see Plan for software boundaries (Office SharePoint Server) and Plan enterprise content storage.

For publishing portals, it is especially important to stay under the limit of 2000 pages per site.

You can use a single farm for both publishing and authoring in an environment that has well-understood and controlled capacity needs. If you do not have well-understood capacity needs, and a tightly-controlled publishing process, we recommend that you split authoring and publishing. This is because Office SharePoint Server 2007 performs best when the types of access and usage patterns for the content in a database are similar. Separating primarily read-only content (publishing) from read-write content (authoring), into different site collections can help.

To help you to best understand and improve performance, we recommend that you focus at the site collection level first, instead of at the site, Web application, or database level. You can use different methods for improving site collection performance. Choose the method that best suits your environment, based on your monitoring results:

• Have different IIS Web applications serve different site collections.

  Use this method if the Web servers are experiencing excessive load. This option enables different processes to access data at the same time, which increases the requests per second that your farm can provide. If the Web servers continue to experience excessive load, consider adding additional Web servers to your farm or splitting into separate farms.

• Put different site collections in different content databases.

  Use this method if the database is under heavy load. This option provides opportunities for I/O parallelism and improved concurrency for SQL Server and SharePoint operations. For additional load separation, you can also host each content database on a different instance of SQL Server or in different SQL Server clusters.

Create a staging environment in the production farm to test whether content deployment is deploying the content you expect, and that your permissions are working correctly. Having a separate staging environment also enables you to lock down changes in an environment without affecting the authoring environment.

It is important to keep current by applying the latest hotfixes, updates, and service packs. These updates contain important product enhancements and improvements. However, make sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments. Follow the recommended procedure for deploying the updates. This includes the following:

• Turn on Windows Update to download updates automatically, but not install automatically.

• Schedule time to install updates at off-peak hours.

• For high availability, rotate servers out of service one at a time during the update process.

Make sure that you are patching the BIOS (server computers, controllers, and disks), Windows operating system, Windows SharePoint Services 3.0 and Office SharePoint Server 2007, and SQL Server.

For more information, view the presentation Understanding and deploying hotfixes, public updates, and service packs (http://go.microsoft.com/fwlink/?LinkId=123927&clcid=0x409) and see the Updates Resource Center for SharePoint Products and Technologies (http://go.microsoft.com/fwlink/?LinkID=106182&clcid=0x409).

If you have to quickly deploy content changes, do not directly edit the destination site because the next time content is deployed, it will be overwritten. Use a quick deploy job to quickly update the site. For more information, see Administer Quick Deploy jobs.

Avoid management tasks and bulk operations during peak hours. This includes deleting lists, sites, site collections or creating new content types or columns. For more information, see White paper: Working with large lists in Office SharePoint Server 2007.

Caching can provide big benefits to a publishing portal. Be sure to use the different types of caching appropriately. When caching is correctly used, it can significantly improve throughput and user response time.

For more information, see Caching in Office SharePoint Server 2007 and the section Optimizing caching for WAN environments in Optimizing Office SharePoint Server for WAN environments.

• Disk-based cache. Disk-based caching controls caching for binary large objects (BLOBs) — for example, image, sound, video files, and javascript (.js) files. When you use the BLOB cache, BLOBs are retrieved from the database on the first request from each Web server and stored in a folder on the file system for the expiration time required by the item. You configure the BLOB cache by using the Web.config file for the Web application in which the cache will be used. For more information, see Disk-based Caching for Binary Large Objects (http://go.microsoft.com/fwlink/?LinkID=123947&clcid=0x409).

• Output cache. Office SharePoint Server 2007 uses output caching technology native to ASP.NET to manage when and how page content is served for publishing portals. When output caching is correctly used, it can significantly improve the throughput and user response time. The page is created once in memory, and maintained in memory.

  For best performance, use as few cache profiles as possible. For more information, see Output caching in Caching in Office SharePoint Server 2007 and Output Caching and Cache Profiles (http://go.microsoft.com/fwlink/?LinkID=121543&clcid=0x409).

• Object cache. Office SharePoint Server 2007 supports caching certain items to reduce the requirement to retrieve field data from the database every time that a page is rendered. The caching system caches complete field data for a page, excluding data for Web Parts on the page. The size of the object cache is set at 100 MB per site collection by default, but you can modify this setting for each site collection to fit the characteristics of the Web site.

  We recommend that you always turn all object caching types on for production environments. For more information, see the section "Object cache tuning" in Caching in Office SharePoint Server 2007.

• Third-party tools--Cache devices. In geographically distributed environments, consider using third-party cache devices or content distribution network (CDN) systems with Office SharePoint Server 2007 to move content closer to users and avoid round-trips. For more information, see WAN accelerators and other third-party tools in Optimizing Office SharePoint Server for WAN environments.

Follow the recommendations in the "Hardware Recommendations" section of Estimate performance and capacity requirements for Internet environments (Office SharePoint Server). For this scenario, focus especially on sizing the Web servers correctly. We recommend that you use 64-bit computers that are running 64-bit Office SharePoint Server 2007, each with four dual-core processors and 16 GB of RAM.

Office SharePoint Server 2007 requires that application pools be recycled regularly. Follow these recommendations to keep sites up and running, even when you have to recycle processes for application pools:

• Recycle application pools at different times for different Web servers (64-bit and 32-bit). If you have multiple Web servers in the farm, make sure that the application pools are set to recycle at different times on different Web servers.

• Recycle application pools at different times for different IIS Web sites (64-bit and 32-bit). Recycle different IIS Web sites at different times in order to avoid peaks on the Web servers. If you have to recycle more than one application pool on a specific Web server at the same time, you should temporarily remove that Web server from the load balancer to avoid bad user experience.

• Consider memory usage for recycling (32-bit). When planning application pool recycling, consider the amount of memory used by each application pool and change the frequency based on the amount of memory used. Application pools that ordinarily use low memory resources will need fewer recycles than others that use lots of memory. We recommend the following settings, although your numbers will vary by how you use your installation and the features that you are using:

  • Configure a virtual memory-based recycle to occur at 1700 MB.

  • Configure the memory used recycle to occur at 1000 MB.

  • Set the shutdown time limit to at least 300 seconds to allow for long-running user requests, such as large file uploads, an opportunity to be completed.

  • Use time-based recycles in environments with regular heavy loads at certain periods of the day. Set a scheduled recycle about 30 minutes before the peak traffic starts.

For more information, see the following resources:

• Recommendations for SharePoint Application Pool Settings (http://go.microsoft.com/fwlink/?LinkId=123977&clcid=0x409)

• Overlapped recycling and SharePoint memory-based recycling (http://go.microsoft.com/fwlink/?LinkId=125985)

• The section "Monitor and manage 32-bit worker process recycling" in Downloadable book: Planning and Deploying Service Pack 1 for Microsoft Office SharePoint Server 2007 in a Multi-server Environment (http://go.microsoft.com/fwlink/?LinkId=125982)

For recommendations for specific counters to monitor, see Good List of Performance Counters (http://go.microsoft.com/fwlink/?LinkId=123925&clcid=0x409).

• Throughput. Track how many requests a server farm can process per second to ensure that you are meeting the expected user response time goals.

• Concurrent users. Track how the number of concurrent users correlates with farm performance.

• Data and site growth over time. Track how quickly the database and site are growing, and project how long the current infrastructure can meet your needs. We recommend that you maintain a level of at least 25% free space across disks to allow for growth. If you are managing growth by adding disks to a RAID array or allocating more storage, monitor disk size closely to avoid running out of space.

The Office SharePoint Server 2007 Content Publishing team thanks the following contributors to this article:

• Simon Skaria, Microsoft SharePoint Customer Advisory Team

• Luca Bandinelli, Microsoft SharePoint Customer Advisory Team

• Steve Peschka, Microsoft Consulting Services

• George Perantatos, Microsoft Enterprise Content Management

• Tyler Butler, Microsoft Enterprise Content Management

• Robert Orleth, Microsoft Enterprise Content Management

• Pat Miller, Microsoft Enterprise Content Management

• Sean Squires, Microsoft Information Services

• Ryan Duguid, Microsoft SharePoint Marketing

Other Resources