Partager via

How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance

  • Article

Summary: Learn how to optimize an Internet-facing Web content management (WCM) site to achieve maximum performance and an effective user experience. (9 printed pages)

Avneesh Kaushik, Microsoft Global Services India (MGSI)

September 2007

Applies to: Microsoft Office SharePoint Server 2007

Contents

  • Overview of Performance Optimization for WCM Sites

  • Managing Page Payload (Small Is Good)

  • Optimizing Server Response Times

  • Designing Site Architecture for Performance

  • Optimizing Your Network Configuration

  • Custom Code, Controls, and Performance

  • Conclusion

  • Additional Resources

  • About the Author

Overview of Performance Optimization for WCM Sites

Performance is a very important aspect of an Internet-facing site, because performance can affect the site's success or failure. Microsoft Office SharePoint Server 2007 enables the deployment of Internet-facing Web content management (WCM) sites. With the many performance optimizations in Office SharePoint Server 2007, you must understand this functionality in depth and design the Internet-facing WCM site from the perspective of performance from the start. In the field, most Office SharePoint Server deployments are intranet oriented, and exposing the site to the Internet has its own challenges, such as page payload (page size). What might not have an impact on an intranet deployment might be a big issue for an Internet-facing site. This article discusses some well-documented and not-so-well documented techniques to improve performance of a SharePoint WCM site. All the general Web site performance best practices apply to SharePoint WCM sites.

Managing Page Payload (Small Is Good)

In Office SharePoint Server, it is very easy to use built-in features to deploy a WCM site with a minimum of effort. However, you have little control over the final HTML that is sent to the client. This article discusses in detail which files are added and the best way to handle them.

SharePoint Core Files

A significant issue you face with a WCM site is that the SharePoint page processing pipeline adds a lot of extra weight to the page payload—or page size—by adding certain default files such as core.js, core.css, init.js, and ie55up.js, which can add approximately 500 KBs uncompressed to the original page size. These extra KBs can add up to 10–20 seconds of download time on slower connections and can make the site performance unacceptable. Office SharePoint Server requires these files to work properly, and Office SharePoint Server adds them automatically to the page at run time. You cannot easily remove or modify them from within Office SharePoint Server. Most WCM sites, however, will require extensive user interface (UI) customization and chances are these files will not be needed. For example, the core.js file, which is required for various Office SharePoint Server functions to work, might not be required if the site does not have any visible SharePoint functionality on the Internet-facing section, but might still be needed for the administration or authoring mode. You can solve this issue in the following ways:

  • Delay load the core .js file (~250 KB uncompressed) in the background (load it asynchronously), which allows the page to load faster and become available to the user more quickly. Delay loading results in a better user experience because the .js file loads asynchronously. This is also the safest option.

  • Load core.js only in cases when it is required; for example, a highly customized Internet-facing WCM site may not require core.js for most of the users except for Site authors or administrators. After this solution is applied to a site, you can achieve a big difference in the performance. However, this option is not officially supported.

To load the core.js file in the background for an anonymous user

  1. Create a custom master page.

  2. Ensure that no Office SharePoint Server controls require core.js as part of the master page for anonymous users (for example, the Site actions menu requires it).

  3. Ensure that the Site master page does not have any ScriptLink controls that register core.js.

  4. Add the following markup to the custom master page or create a new page layout and add the markup to the layout. The decision to add the Scriptlink control to the master page or page layout depends on whether you want to implement the core.js file delayed load behavior across the site or for only specific pages based on the new custom page layout.

    <SharePointWebControls:ScriptLink />

  5. Create a new Microsoft Visual C# class project. Copy the code from Section A (see the following procedure). Compile the code to create a new binary NoCoreLoad.dll.

  6. Add NoCoreLoad.dll to the global assembly cache or _app_bin (for the Web application).

  7. Add the following line in the web.config file of the Web application, with the correct public key token if added in the global assembly cache.

    Note

    This code example includes line breaks to facilitate online viewing. You must remove the line breaks before running the code.

    <SafeControl Assembly="NoCoreLoad, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=XXXXXXXXXX" Namespace="Microsoft.IW" TypeName="*" 
Safe="True" />

  8. Add a tag to register the new binary. It will look something like the following (but with a different PublicKeyToken).

    Note

    This code example includes line breaks to facilitate online viewing. You must remove the line breaks before running the code.

    <%@ Register TagPrefix="NoCoreLoad" Namespace="Microsoft.IW" 
Assembly="NoCoreLoad, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=XXXXXXXXXXXXXXXXX" %>

  9. Add the following markup at the top of the page within the Header, next to any other .js files.

    <NoCoreLoad:RegisterCoreWhenAuthenticatedControl />

  10. Copy the CorePreLoad.aspx file content (see Section B in the next procedure) to the _layouts directory on the server. (This loads the core.js file asynchronously.)

  11. If you are using page layout, in the master page used by the site add a new placeholder in the markup after the </form> tag and before the </body> tag that looks like the following.

    <asp:ContentPlaceHolder id="PlaceHolderBottomIFrame"  />

    Then add the following markup in the page layout.

    <asp:Content ContentPlaceholderID="PlaceHolderBottomIFrame" >
<iframe src="https://blogs.msdn.com/_layouts/CorePreLoad.aspx" style="display:none"/>
</asp:Content>

  12. Otherwise, if you are making the following change only in the master page (site wide), add the previous markup in the master page instead of in the placeholder.

If you perform the previous steps by using a new page layout and not just the master page, you must create a new page based on the page layout to test the functionality.

To load the core.js file conditionally, where core.js is loaded only in the case of authenticated users

  1. Repeat the steps in the previous procedure until Step 9, and then skip the steps that follow Step 9.

    If you do this, core.js is loaded only for authenticated users. In the case of anonymous users, core.js is not loaded at all. The logic in the Section A code example can be further modified to load core.js only in the case of an NTLM authenticated user, if required. For example, users authoring the content need core.js and most often these users are Windows authenticated users. In these cases, it is appropriate to load core.js only for authenticated NTLM users.

    Note

    This code example includes line breaks to facilitate online viewing. You must remove the line breaks before running the code.

    Section A: NoCoreLoad.Dll

    using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.SharePoint;
using System.Xml;
using System.Xml.Serialization;

namespace Microsoft.IW
{
    public class RegisterCoreWhenAuthenticatedControl : WebControl
    {
        protected override void OnInit(EventArgs e)
        {
            if (HttpContext.Current.Request.IsAuthenticated)
            {

                 Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
            }
            base.OnInit(e);
        }
    }
}

    Section B: CorePreLoad.aspx

    <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" 
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c" %>
<html>
<head>
<title>Pre-Load Core.js</title>
</head>
<body>
<SharePoint:ScriptLink name="core.js"  />

<script language="javascript">
 DisableRefreshOnFocus();
</script>

</body>
</html>

Browser Cache Settings

There are a few browser or client cache settings that can affect how and how often assets (for example, images or .js files) are loaded. If these settings are configured properly, they can affect the performance on subsequent loads of the same files. This is the case in most scenarios. Proper configuration will also save bandwidth use for both the server and client. These settings are affected by the setting of the caching profiles and by the configuration of the BLOB or disk cache on the server running Office SharePoint Server, which I discuss in detail in the next section.

You can also use MetaTagsGenerator to control how a specific page is cached on the client, when it expires, and so on.

<meta name="expires" content="Wed, 7 Mar 2006 15:52:37 GMT">
<meta http-equiv="cache-control" content="max-age 10">

By tweaking these tags, you can make a big difference in general page loading and rendering, which can enhance the user experience.

IIS Compression

A significant option that is available to improve SharePoint site performance (especially in the case of pages that are large in size) is to set Internet Information Services (IIS) compression. The option to change IIS compression is provided in IIS 6.0. Switching on IIS compression on a SharePoint site is not straightforward, however, and you need to understand some things before you can proceed.

IIS offers two types of compression capabilities:

  • Static compression To compress static assets such as .js files, .html files, and others (not including images because images are already compressed). Static compression is a very straightforward and simple process with little or no impact on server load. In this approach, the files are compressed the first time they are accessed, and are kept in a temporary folder and served to the user from the temporary directory from then on. In most cases, you can easily achieve more than 50 percent compression and a great reduction in file sizes. In the case of Office SharePoint Server, all files in _layout directories (for example, .js files and .html files) are compressed. All other files, including files that are static in nature, are not treated as static if they are stored inside Office SharePoint Server. Mostly the large core.js file is compressed, and its size is reduced from about 250 KB to 57 KB. In addition, other system .js files such as init.js and init55up.js are compressed, which solves our biggest problem involving page size.

  • Dynamic compression Switching on dynamic compression for SharePoint sites is not a good option and one should avoid it. For more information about compression options, see SharePoint Deployment Capacity & Performance Planning 2003 & 2007: What you need to know....

Master Page and Page Layout Design

It is also very important to design your master pages and page layouts at the start of the site development with performance in mind. The same old best practices for HTML development should be considered.

Best practices in HTML

For the document:

  • The document must validate as HTML or XHTML (W3C Markup Validation Service).

    Note

    Office SharePoint Server, by default, is not XHTML compliant.

  • The document must have a DTD.

  • The document must have character encoding (W3C Recommendation: 5.2.1 Choosing an encoding), either through an HTTP header or a metatag.

  • The document should have the language defined in the following ways:

    <html lang="en"> 
<html xml:lang="en"> 
<meta name="content-language" content="en">

For attributes and elements:

For images:

For special characters:

For script and style tags:

Of course, regarding browser cache (Performance Research, Part 2: Browser Cache Usage—Exposed!) and HTTP requests (Performance Research, Part 1: What the 80/20 Rule Tells Us About Reducing HTTP Requests), we could discuss whether external files load faster with several server requests through script src="sample.js" or by using one request and internal HTML code. But in either case, you should use and include central, nonredundant files.

Best Practices in CSS

  • CSS must validate (CSS Validation Service).

  • Elements should be positioned with CSS 2, not tables.

  • All ornamental lines, borders, background colors and images, underlines, and other decorational elements should be rendered with CSS 2.

  • Text should be formatted with CSS 1, not with font tags.

  • All style sheets should be included in reusable, centrally maintainable, and cacheable external CSS files, not included as redundant code within the HTML files.

  • External CSS files should be sent with the correct MIME type (text/css).

  • CSS classes and IDs must be valid, for example, beginning with a letter, not a number or an underscore. IDs must be unique. Class names should be generic, and describe functionality rather than appearance.

Optimizing Server Response Times

Office SharePoint Server 2007 offers many options to optimize server-side response of WCM pages and also reduce the load on Office SharePoint Server servers and back-end servers running Microsoft SQL Server.

There are a few caching options that you can enable in Office SharePoint Server to improve server-side performance. In the following sections, I discuss how to switch them on and what to be careful about while configuring them.

In most cases on an Internet=facing site, most of the users are anonymous. Using output caching in these scenarios can make a big difference in overall performance of the site.

Output Caching

The same technique provided by ASP.NET is used by Office SharePoint Server 2007 to cache parts of the page to handle subsequent page requests. By saving the HTML markup in a cache, ASP.NET is able to serve up Web pages much faster with less CPU usage and fewer database roundtrips, because it does not need to run code to generate the same HTML markup every time the page is requested.

Before output caching can be enabled, you must enable the MOSS Publishing Infrastructure feature for the site collection, if it is not enabled already. Whether it is enabled by default depends on the site template that is selected when you create the site collection.

Be aware of the following while configuring output caching:

  • Output caching is ideal for Web sites that do not require frequent content updates.

  • Output caching is more effective when the access is anonymous.

  • Output caching consumes additional memory to cache the HTML markup for each cached page.

  • When used with two or more front-end Web servers, output caching can affect consistency.

  • Enabling caching for authenticated users who can author content can cause issues, because they might not be using the most up-to-date content.

  • If you need to optimize the performance more, you can specify output caching behavior at three levels: site collection, site, and page layout.

  • In an environment employing user authentication, you should never cache search results.

  • If output caching is enabled, you might want to extend the default ASP.NET 2.0 limit on private bytes.

  • Grouping authenticated users and then enabling caching behavior based on a user's access rights to a site can improve cache performance for authenticated users.

There are two main scenarios for which you must create cache profiles. In most cases, there are two types of users: anonymous and authenticated. All anonymous users share the same cached content, but this is not correct for authenticated users. Authenticated users share only content cached for that user. This can reduce the cache hit ratio considerably. A solution to overcome this behavior is to group people into groups or roles so that they can share the same cached content, which results in a better use of resources.

To create or edit a cache profile

  1. Create or edit a cache profile that specifies the behavior of output caching, as shown in Figure 1.

    Figure 1. Cache profile

    Cache profile

  2. Ensure that you understand the following properties and how to use them:

    • Enabled (turns on caching)

    • Duration (amount of time to keep cache content)

    • Vary by HTTP header

    • Cacheability (how cache will behave)

To enable the output cache

  1. Set the cache profile for anonymous users and authenticated users. You can set different profiles for each type of user.

    Figure 2. Output cache settings

    Output cache settings

  2. Select the Enable debug cache information on pages check box to test how the caching is working. Enabling this option adds "<!-- Rendered using cache profile:Public Internet at: 2006-11-03T14:38:59 -->" to the bottom of each page served by Office SharePoint Server.

Disk-based Caching

In an Internet-facing Web site, you have extensive UI customizations, which means there are many large images, .css files, and .js files stored on the server running Office SharePoint Server. These files are stored as BLOBs inside a SQL Server database (if stored in SharePoint libraries like a style library, Site collection images, and so on) and can impact server performance adversely. These files also add stress to back-end SQL servers. Office SharePoint Server provides disk-based caching, also called BLOB caching, to solve this problem. Disk-based caching is extremely fast and eliminates the need for database roundtrips because these objects are retrieved from the database once and then stored on the file system of the front-end Web servers. Additional requests are served from the cache and trimmed based on security. This option is disabled by default, and you must modify the following line in the web.config file of the Web application for each front-end Web server in the server farm.

<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="false"/>

In the previous XML, notice the following:

  • location is the directory where the cached files will be stored.

  • path specifies in the form of a regular expression which files are cached based on the file name extension.

  • maxSize is the maximum allowable size of the disk-based cache in gigabytes (GBs).

  • max-age specifies the maximum amount of time in seconds that the client browser caches BLOBs downloaded to the client computer. This affects the cache metatag sent as part of the page header to the browser. This can have a large impact on the client-side performance, especially for slow connections. Most of the .js files and image files are downloaded and kept in the client cache and are not reloaded for the time specified in this property.

  • enabled specifies a Boolean value that disables or enables the cache.

Disk-based caching reduces the downloading time of images, js files, and other assets on every request. The number of seconds specified in the max–age segment tells the browser to load the asset from the local cache and to not even check the server if the file has changed. The browser checks back file status only after the specified seconds pass and reloads the image if it finds a change.

Also, the Master Page gallery and Style Library do not work by default for anonymous users; for BLOB caching to work for these lists, you must go to these lists and explicitly switch on anonymous access for BLOB caching.

Object Cache

Office SharePoint Server 2007 stores all the content and objects, such as Web Parts, navigation data, and data accessed through cross-list queries, in SQL Server databases. These items are not cached by disk-based caching or output caching. Object caching, which is switched on by default, helps in this case. Caching improves the cross-list query's performance. Object caching also caches page field data, improving page rendering. However, Web Parts and related data are not cached.

The default size of the object cache is 100 MB, and it is very important to tune this number to get the most out of this cache. Setting the size too high without checking the cache hit ratio can waste valuable memory, which could have been used by other caches. A bigger object cache can impact performance adversely, because it affects output cache negatively on 32-bit computers.

It's a good idea to profile the object cache using a default value by using the SharePoint Publishing Cache Object performance counter object. Based on the cache hit ratio and the change in Object Discard counters, you can increase the object cache size accordingly.

Designing Site Architecture for Performance

The architecture and design of a SharePoint-based site (which includes its physical design, topology, and more) can have a significant impact on its performance

Much depends on the hardware and topology of the Office SharePoint Server farm, so you should:

  • Adhere to the general guidelines given on SQL Server 2005 System Requirements for SQL Server hardware requirements and connectivity to the front-end Web servers.

  • Segregate application servers, index servers, and front-end Web servers on different physical servers.

  • Ensure proper connectivity between servers.

  • Scale up servers running SQL Server and scale out front-end Web servers based on load and demand.

The following resources can provide you with more information when you are planning a SharePoint site:

For hardware and software requirements

For planning and other background information about Office SharePoint Server

Recommended deployment topologies for WCM

It is also very important to follow best practices for designing site collections and related libraries. Following are some of the components you should consider carefully:

  • The maximum number of pages per site (should be 2000); more items than this in a list can adversely affect performance

  • Use one page library per site

  • The number of site collections per database

  • The size of each database

  • The number of databases per SQL Server instance

  • The total database size on a given SQL Server instance

  • The portal sites per farm, extended IIS virtual servers, and Web applications

  • The application pools per server

  • The worker processes per server and application pool

  • The site collection max quota

For more specific details, see SharePoint Deployment Capacity & Performance Planning 2003 & 2007 What You Need to Know....

Geographically Distributed Web Server Farms

One extreme approach in designing a very high-performance Web site is to have it distributed or mirrored across geographies. The number of hops between the client and the Web site server can also impact performance and general user experience. For example, a Web server located in the United States, when accessed by a person in Europe, will have slightly more network delay than for a person located in the United States who is accessing the same site. Office SharePoint Server 2007 provides the ability to publish content to different destination servers, which can facilitate synchronization of content automatically between various geographically disparate servers. Again, this mechanism is based on content deployment that uses publishing jobs and APIs; Office SharePoint Server does not support any type of replication.

Optimizing Your Network Configuration

Network configuration is critical to the performance of your Office SharePoint Server or Windows SharePoint Services installation. Table 2 describes some common network components that can affect your installation's performance.

Table 2. Network components that can affect your installation's performance

Item Description

Network Interface Card (NIC)

  • NIC settings: Where possible, you should always use gigabyte network cards. If you have self-switching cards (100 MB / 1 GB), you should always set the override to use 1 GB.

  • Inbound/Outbound: For scenarios where you expect high traffic, I recommend you have separate NICs to handle inbound and outbound traffic.

Switches

If you run your network through a switch, ensure that you are using a GB switch and that you have the same number of inbound/outbound channels.

Routers

Ensure your routers are configured on a GB infrastructure.

Domain controllers

It is possible for authentication to become a performance bottleneck in your SharePoint environment if the domain controller (DC) receives requests more quickly than it can respond. For environments using user authentication such as NTLM, I recommend a ratio of 3 front-end Web servers per DC. If your tests indicate that the authentication load at 3 front-end Web servers per DC is acceptable, you can add one more front-end Web server per DC for a supported limit of 4 front-end Web servers per DC.

Remember to plan and test network configuration thoroughly prior to moving a system to a production environment.

For more information, see "Environmental factors" in Additional Performance and Capacity Planning Factors (Office SharePoint Server).

Custom Code, Controls, and Performance

One of the most neglected areas of consideration in a SharePoint site is custom code or custom controls. And these controls can have a mostly adverse impact on Office SharePoint Server performance.

Consider the following aspects when developing custom controls:

  • SQL Server roundtrips

  • CPU utilization

  • Page download size

  • Client-side code efficiency

  • AJAX callbacks

It is equally important to develop cache-aware custom controls. Custom controls in master pages and page layouts should minimize server roundtrips and use built-in Office SharePoint Server cache features such as building navigation providers that always use the object cache and creating content queries that use the Content By Query cache. It is always a good idea to code the controls so that they use the built-in caching abilities of ASP.NET. In addition, remember general good coding guidelines, for example, disposing promptly of SharePoint objects that are no longer in use and keeping view state to the minimum. Wherever possible, using data that is available in the Office SharePoint Server cache can help to vastly improve performance.

Office SharePoint Server provides many base control classes to optimize custom control performance, such as the CrossListQueryCache class and others.

Conclusion

For Internet-facing WCM sites, performance is a very important factor as compared to an intranet installation. Performance is affected by many factors, for example, environment, controls, UI, and design. It takes more effort to properly design a WCM site than a simple Web site. Office SharePoint Server 2007 provides many ways to fine-tune configurations to get the best performance from the hardware that is in use. Be aware of all the available options Office SharePoint Server gives you, and learn to use them. A properly configured Office SharePoint Server deployment can give you very good results if you adhere to the guidelines I address in this article.

Additional Resources

For more information about optimizing an Internet-facing WCM site to achieve maximum performance and an effective user experience, see the following resources:

About the Author

Avneesh Kaushik is a senior consultant working with Microsoft Global Services India (MGSI) in the IW/Collaboration service line. He has helped design and deploy the Hawaiian Airlines WCM site.