Best practices for publishing portals

  • Article

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

This article is one of a series of Best Practices articles for Microsoft Office SharePoint Server 2007. This article describes the typical characteristics and best practices for publishing portals based on Office SharePoint Server 2007. For more articles in the series, see Best practices. For additional information and resources regarding Best Practices for Office SharePoint Server 2007 see the Best Practices Resource Center (https://go.microsoft.com/fwlink/?LinkId=125981).

Publishing portal environments typically exhibit the following characteristics:

  • Security. Internet-facing portal environments typically allow anonymous authentication for most users. Membership sites and intranet portals have more varied authentication and authorization environments.

  • User operations. Most user operations on the site are reads.

  • Cache-hit ratio. For read-only content, we expect a cache-hit ratio of approximately 99 percent.

1. Deploy at least three front-end Web servers

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).

2. Make query-driven Web Parts efficient

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:

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.

4. Separate authoring and publishing environments

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.

5. Separate your staging environment from the authoring environment

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.

6. Make sure you have the latest updates installed!

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 (https://go.microsoft.com/fwlink/?LinkId=123927&clcid=0x409) and see the Updates Resource Center for SharePoint Products and Technologies (https://go.microsoft.com/fwlink/?LinkID=106182&clcid=0x409).

7. Do not edit the destination site directly

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.

8. Avoid management tasks and bulk operations in the authoring environment during peak hours

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.

9. Use caching!

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 (https://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 (https://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.

11. Set application pool recycling settings for better availability

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:

12. Monitor key counters to manage performance

For recommendations for specific counters to monitor, see Good List of Performance Counters (https://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.

Acknowledgements

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

See Also

Other Resources

TechNet Webcast: Best Practices for Developing, Deploying, and Maintaining Forms Solutions