HTTP Compression, Internet Information Services 6.0, and SharePoint Products and Technologies

A recent discussion on Garbage Collection management on 64-bit Web servers hosting Microsoft Office SharePoint Server 2007 led into a discussion on rendering performance, particularly steps to reduce overall rendering time at the client.  While monitoring client rendering can be achieved to some degree through measuring TTLB – purely in ensuring pages are served in a timely manner (see ASP.NET Performance Monitoring, and When to Alert Administrators for monitoring recommendations), there are too many variables that can result in overall performance variations to include browser, hardware, machine state, etc.  The most commonly implemented measures to improve client-side performance are object and output caching natively within Microsoft Office SharePoint Server 2007; however, often overlooked as a performance improvement mechanism is HTTP compression in Internet Information Services 6.0.  This article describes the basic steps to enabling HTTP compression in Internet Information Services 6.0.

Step 1 Enable Compression (Global)

  1. Open a Command Prompt and run the following script: cscript C:InetpubAdminScriptsadsutil.vbs set w3svc/filters/compression/parameters/HcDoStaticCompression true to enable compression on all Web applications installed on the current server farm.  (See later in this article references to enabling compression on sites and site elements).

Step 2 Specify File Extensions

  1. Open a Command Prompt and run the following script: cscript adsutil.vbs SET W3SVC/Filters/Compression/Deflate/HcFileExtensions "css js" to enable static compression on the file extensions denoted within the “” string.  CSS (Cascading Stylesheets) and JS (JavaScript) will provide the most in respect to performance gains with SharePoint Products and Technologies, for example, see the attached image of the compressed files directory on a single page view.  NOTE The size and location of the compression directory for static compression can be configured through modifying the HcCompressionDirectory, HcDoDiskSpaceLimiting, and HcMaxDiskSpaceUsed metabase properties.  Always backup the IIS Metabase before making any changes, for additional information on backing up the IIS Metabase visit http://www.microsoft.com/technet/serviceproviders/wbh4_5/CMSU_DR_Run_CONC_Back_Up_IIS_Metabase.mspx?mfr=true.

image
The sample image assumes a single render of a Microsoft Office SharePoint Server 2007 Publishing Page

Step 3 Create a Web Service Extension

Create a Web Service Extension referencing the gzip assembly for compression:

  1. Open Internet Information Services 6.0 Manager, expand the <SERVER_NAME> (local computer) node and right-click the Web Service Extensions node.
  2. Select Add a new Web service extension… from the menu.
  3. Specify a descriptive name for your Web Service Extension, for example, Compression, IIS Compression, etc. in the Extension name: field.
  4. Click Add… under Required files… and a reference to C:WINDOWSSystem32inetsrvgzip.dll.
  5. Select the checkbox labeled Set extension status to allowed and click OK on the New Web Service Extension window.

Step 4 Configure the IIS MetaBase

  1. Open C:WINDOWSsystem32inetsrvMetaBase.xml in a text editor (Notepad)
  2. Locate the <IISCompressionScheme> element.
  3. Find the HcScriptFileExtension metabase property and add aspx and asmx to the existing list ensuring the entries conform to the existing format, next modify the HcFileExtensions metabase property to specify any additional files to be compressed aside from those configured in the previous steps through adsutil.vbs.  The HcScriptFileExtension metabase property specifies dynamic files to be compressed when HTTP compression is enabled whereas the HcFileExtensions metabase property specifies static files.  NOTE Changes should be applied to both the deflate and gzip compression schemes.
  4. Modify the HcDynamicCompressionLevel to a value between 0 and 10, 0 being low compression and 10 being maximum compression.  The HcDynamicalCompressionLevel

NOTE You should consider testing the impact of varying compression levels in a laboratory environment closely monitoring CPU utilization and potential impact to your Web servers.  Typically a compression level between 7 and 9 provides optimum performance vs. CPU load in most circumstances.  If you are running IIS 7.0 see http://msdn2.microsoft.com/en-us/library/bb386460(vs.85).aspx for a description of IIS 6.0 to IIS 7.0 Metabase property mappings.

Sample MetaBase.xml [Snippet]

<IIsCompressionScheme Location=”/LM/W3SVC/Filters/Compression/deflate
        HcCompressionDll=”%windir%system32inetsrvgzip.dll
        HcCreateFlags=”0
        HcDoDynamicCompression=”TRUE
        HcDoOnDemandCompression=”TRUE
        HcDoStaticCompression=”FALSE
        HcDynamicCompressionLevel=”9
        HcFileExtensions=”htm
            html
            css
            js

        HcOnDemandCompLevel=”10
        HcPriority=”1
        HcScriptFileExtensions=”asp
            exe

>
</IIsCompressionScheme>
<IIsCompressionScheme Location=”/LM/W3SVC/Filters/Compression/gzip
        HcCompressionDll=”%windir%system32inetsrvgzip.dll
        HcCreateFlags=”1
        HcDoDynamicCompression=”TRUE
        HcDoOnDemandCompression=”TRUE
        HcDoStaticCompression=”TRUE
        HcDynamicCompressionLevel=”9
        HcFileExtensions=”htm
            html
            css
            js

        HcOnDemandCompLevel=”10
        HcPriority=”1
        HcScriptFileExtensions=”asp
            exe
            axd

>
</IIsCompressionScheme>

In the sample metabase snippet above both deflate and gzip are enabled, it is not recommended to disable one or the other due to potential for unintended consequences such as failure to compress responses to a particular browser, e.g. compatibility issues.  In some cases you may wish to enable compression at only the site or site element level as opposed to global application.  To disable compression open a Command Prompt and run the following script:  cscript C:InetpubAdminScriptsadsutil.vbs set w3svc/filters/compression/parameters/HcDoStaticCompression false.  To enable compression on sites or individual site elements see http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx?mfr=true.

Step 5 Restart the World Wide Web Publishing Service

  1. Open a Command Prompt and enter NET STOP W3SVC and allow the World Wide Web Publishing Service to stop.  When the World Wide Web Publishing Service has stopped, enter NET START W3SVC.

To determine whether or not affordable gains were provided through enabling HTTP compression you should baseline server performance both prior to and following enabling of HTTP compression using the Processor% Processor Time and Network InterfaceBytes Sent/sec performance monitor counters.  Generally where the Processor% Processor Time value exceeds 80%, HTTP compression is not recommended.

Regardless on whether or not you elect to leverage HTTP compression the important takeaway from this conversation is that SharePoint Products and Technologies performance can be improved beyond the native concepts available to the platform such as Site Output and BLOB Caching which I am planning separate posts to provide prescriptive guidance on implementation.

Resources

Enabling HTTP Compression (IIS 6.0)

Using HTTP Compression for Faster Downloads (IIS 6.0)

Customizing the File Types IIS Compresses (IIS 6.0)

Troubleshooting HTTP Compression in IIS 6.0

Upcoming Posts

The next three (3) weeks will indeed be busy for me, first traveling to Amsterdam to meet with customers and returning to Redmond the following week to speak at TechReady6 on securing and protecting SharePoint Products and Technologies deployments; however, with that will come some compelling content I hope to publish toward the end of the month and early February.  Next week I am focused on performance, particularly, discussions on Garbage Collection (GC) and GC management on 64-bit Web servers.


Keep reading…

Microsoft Office Developers Conference 2008

The Microsoft Office Developers Conference 2008 is less than one month away.  The Microsoft Office Developers Conference is the premier event for both Microsoft Office and SharePoint Products and Technologies developers.  Visit https://microsoft.crgevents.com/ODC2008/Content/default.aspx?p=UC3HYF to learn more or register for the event which runs between February 10th – 13th, 2008 in San Jose, CA at the San Jose Convention Center.  The Microsoft Office Developers Conference 2008 will include a set of keynotes by senior Microsoft executives, five (5) technical tracks, 90 break-out sessions and hands-on labs in addition to an Executive Track where analysts, Microsoft and industry executives can learn the how and why of Office applications and their respective competive advantages.


Keep informed by subscribing to the Microsoft Office Developers Conference 2008 blog at http://blogs.msdn.com/odc2008/default.aspx.

Dynamic Application of Master Pages in Microsoft Office SharePoint Server 2007

I’ve spent the past two months in various locations across the West coast speaking on governance in SharePoint Products and Technologies and one of the most common points of discussion is enabling a consistent look and feel across sites and Webs.  While most commonly this is achieved through employing a master page, many organizations either limit the distribution of Microsoft Office SharePoint Designer 2007 or do not use Microsoft Office SharePoint Designer 2007 in their organizations, while there are many articles across numerous blogs providing prescriptive guidance on master page development, Feature stapling, and other variations to support the implementation of master pages, I’ve yet to find a complete tutorial on implementing master pages using a combination of Feature stapling and a Feature Receiver.


NOTE Sample master pages can be downloaded from: http://www.microsoft.com/downloads/details.aspx?FamilyID=7c05ca44-869a-463b-84d7-57b053711a96&DisplayLang=enClick here to download sample master page resource files based on the Clarity master page included in the Windows SharePoint Services 3.0 Sample: Example Master Pages.  The Clarity master page in this download was modified to support installation as a Windows SharePoint Services 3.0 solution package.


Create the Solution Directory Structure


The directory structure is important to the solution when it is to be compiled using MAKECAB.exe later in this article, to simplify the compilation using MAKECAB.exe you should create a directory structure relative to the location on which the files will be installed on the Web server(s), the directories when the solution is added and deployed to the server farm are relative to %commonprogramfiles%Microsoft SharedWeb Server Extensions12 in this example.


+ Sample Master Page Solution


  + GAC Hosts the Feature Receiver called by the Feature


  +  TEMPLATES


    + FEATURES


      + Sample.MasterPage Hosts the master page feature scoped at the Site level and MasterPages subdirectory.


        + MasterPages Hosts the master page or master pages that will be used by the solution.


      + Sample.Stapler Hosts the stapling Feature that makes the master page(s) available to the Site and Web scopes.


      + Sample.Web.Master Hosts the master page feature scoped at the Web level.


    + LAYOUTS


      + <LocaleID>


        + Styles *Optional Hosts cascading stylesheets used by out of the box master pages and page layouts.


          + Sample *Optional Hosts cascading stylesheets used by the master page.


    + IMAGES


      + Sample *Optional Hosts images used by the master page.


Create the Master Page Feature (Scope = Site)


The master page feature contains both the files necessary to provision a Feature and the master page to be applied to newly created sites. The master page Feature directory should contain a directory to host the master page and two files, Feature.xml and ProvisionedFiles.xml.


Feature.xml


Feature.xml defines the base properties of the Feature and lists elements bound to it.


NOTE For more information see the Working with Features article on MSDN at http://msdn2.microsoft.com/en-us/library/ms460318.aspx.


Elements and Attributes


The <Feature> element defines the Feature and specifies the location of assemblies, files, dependencies, and additional properties supporting the Feature.  In Feature.xml the Title attribute specifies the name of the Feature as it appears in the SharePoint Products and Technologies user interface and is supported by the Description attribute which can be used to specify additional descriptive text to identify the Feature.  It is best to provide a clear description of the Feature, it’s purpose and scope in the Description attribute to easily identify the Feature in the SharePoint Products and Technologies user interface.  The Scope attribute specifies the scope at which the Feature applies itself, in this example, the scope is at the Site level.  The Hidden attribute specifies whether or not the Feature is visible in the SharePoint Products and Technologies user interface and the DefaultResourceFile specifies the default resource file used by the Feature.


The ElementManifests element specifies references to element manifests and element files that contain definitions for the Feature elements.


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Feature  Id=”<GUID>”
          Title=”Sample Site Collection Master Page
          Description=”The sample master page provides an instant style ready to be applied to your SharePoint site.
          Version=”1.0.0.0
          Scope=”Site
          Hidden=”False
          DefaultResourceFile=”core
          xmlns=”
http://schemas.microsoft.com/sharepoint/>
    <ElementManifests>
        <ElementManifest Location=”ProvisionedFiles.xml/>
    </ElementManifests>
</Feature>


ProvisionedFiles.xml


ProvisionedFiles.xml defines the resources that are provisioned on the Web server as a component of the underlying associated Feature.


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Elements xmlns=”
http://schemas.microsoft.com/sharepoint/>
<Module Name=”OSGMasterPagesUrl=”_catalogs/masterpagePath=”MasterPagesRootWebOnly=”TRUE“>
        <File Url=”Clarity.master” Type=”GhostableInLibrary”>
            <Property Name=”ContentTypeValue=”$Resources:cmscore,contenttype_masterpage_name;” />
            <Property Name=”PublishingPreviewImageValue=”/_layouts/images/clarity/clarity.gif/>
            <Property Name=”MasterPageDescriptionValue=”Clarity Master Page/>
        </File>
</Module>
</Elements>


In the example the preview image for the master page is stored in a subdirectory, clarity relative to %commonprogramfiles%Microsoft SharedWeb Server Extensions12BIN.  It is recommended to create resource directories to host supporting content to easily identify resources associated with the master page on the Web server file system.


Create the Master Page Feature (Scope = Web)


The master page feature contains both the files necessary to provision a Feature and the master page to be applied to newly created Webs. The master page Feature directory should contain two files, Feature.xml and ProvisionedFiles.xml.


Feature.xml


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Feature  Id=”<GUID>”
          Title=”Sample Web Master Page
          Description=”The sample master page provides an instant style ready to be applied to your SharePoint site.”
          Version=”1.0.0.0
          ReceiverAssembly=”SampleReceiver, Version=1.0.0.0, Culture=neutral,PublicKeyToken=<PKT>
          ReceiverClass=”SampleReceiver.FeatureReciever
          Scope=”Web
          Hidden=”False
          DefaultResourceFile=”core
          xmlns=”
http://schemas.microsoft.com/sharepoint/>
    <ElementManifests>
        <ElementManifest Location=”ProvisionedFiles.xml/>
    </ElementManifests>
    <Properties>
      <Property Key=”MasterNameValue=”Clarity.master/>
    </Properties>
</Feature>


The Web master page Feature has two notable differences in comparison to the sites master page Feature, the ReceiverAssembly attribute and its dependencies and the <Properties> element that defines the master page to be applied when the custom code is called in the Feature Receiver specifies in the ReceiverAssembly attribute and dependant attributes.


The ReceiverAssembly attribute specifies the assembly name (instructions later in this article).  The Version and Culture attributes specify the assembly version and Culture.  The PublicKeyToken attribute specifies the Public Key Token for the assembly.  Once the assembly is compiled in Visual Studio you can use the Strong Naming utility SN.exe or optionally copy the assembly to your Global Assembly Cache to retrieve the Public Key Token.  NOTE Assemblies must be signed to support installation in the Global Assembly Cache.


ProvisionedFiles.xml


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Elements xmlns=”
http://schemas.microsoft.com/sharepoint/></Elements>


Create the Master Page Stapling Feature


Feature.xml


Feature.xml defines the base properties of the Feature and lists elements bound to it.  NOTE For information on Feature.xml elements and attributes used in this solution, see Elements and Attributes in the Create the Master Page Feature section at the top of this article.


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Feature  Id=”<GUID>”
          Title=”Sample Stapler
          Description=”Sample stapler feature.
          Version=”1.0.0.0
          Scope=”Farm
          Hidden=”False
          DefaultResourceFile=”core
          xmlns=”
http://schemas.microsoft.com/sharepoint/>
    <ElementManifests>
        <ElementManifest Location=”ElementsManifest.xml/>
    </ElementManifests>
</Feature>


The stapling Feature enables the association of a specific Feature with a site definition.  The stapling Feature directory should contain two files, Feature.xml (described above) and ElementManifest.xml.


ElementManifest.xml


ElementManifest.xml contains definitions for the Feature elements.


The <FeatureSiteTemplateAssociation> element specifies the site templates the Feature should be associated to.  In ElementManifest.xml the Id attribute specifies the globally unique identifier for the site template the Feature should be associated and the TemplateName attribute specifies the friendly name of the template associated with the globally unique identifier in the Id attribute.  In this example, the Feature is associated with an example collection of the out of the box site definitions for both sites and Webs, use additional Site Templates as needed by adding the identification values in the <Elements> element.


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Elements xmlns=”
http://schemas.microsoft.com/sharepoint/>
  <!–Clarity.MasterPage Feature–> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#0” /> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#1” /> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#2” />


  <!–Clarity.Web.Master Feature–> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#0” />  
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#1” />
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#2” />
</Elements>


Create the Feature Receiver


The Feature Receiver provides the ability to respond to Feature events which permit trapping and responding to an event that fires when a Feature is installed in the Web farm, added to a Web application, or when a Feature is removed.  For additional information on Feature Events see http://msdn2.microsoft.com/en-us/library/ms469501.aspx or for additional information using Feature Receivers to modify master page properties and application on a SPWeb object see http://blogs.msdn.com/bgeoffro/archive/tags/branding/default.aspx.


The Feature Receiver is the core of the master page solution and enables a method by which an event is acted on when the Feature function or functions are called.  The Feature Receiver used in this example is called by the Clarity.Web.Master Feature.  Event handlers within the Feature Receiver class are fired when the Feature is installed, activated, uninstalled, and/or deactivated.  To instruct the SPWeb object to use the new Master Page you would supply the necessary code inside the FeatureActivated Event Handler.


Create the SharePoint Solution Package


The SharePoint solution package will contain the Feature resource files and receiver created in the steps above.  There are several applications available today specifically designed to create and compile SharePoint solution packages; however, most commonly the MAKECAB.exe application is used to create the solution package.  To download and learn more about MAKECAB.exe visit http://support.microsoft.com/kb/310618.  For solution packaging examples using MAKECAB.exe see Deploying ProClarity Viewer 6.3 for SharePoint and Understanding Solution Packages in Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0.


Resources


Chris Johnson:  Feature Stapling in WSS v3 http://blogs.msdn.com/cjohnson/archive/2006/11/01/feature-stapling-in-wss-v3.aspx


Heather Solomon:  Create a Feature: Master Pages for Site Collections http://www.heathersolomon.com/blog/articles/servermstpageforsitecollect_feature.aspx


Andrew Connell:  Adding Master Pages to WSS v3 Site Collections via Features http://andrewconnell.com/blog/archive/2006/10/21/4954.aspx


Brett’s SharePoint Blog:  Branding http://blogs.msdn.com/bgeoffro/archive/tags/branding/default.aspx *Great Code Samples