Friday, March 14, 2008

SharePoint MOSS 2007 - Why is my new SharePoint site so slow?

If you've just installed SharePoint/MOSS, you'll find that any brand spanking new sites you make are amazingly slow, even without any custom content. Why? It's because SharePoint stores -all- content in the Content Database. That means every single image, css file, js file...everything used to make up a single webpage is queried from the database, slapped together by the MOSS framework, then pushed to your client. All those hits to the database on every single page request turns even the simplest site into a horribly slow web application.

What can I do to make SharePoint faster?!

Our first step in speeding up a SharePoint site is to tell SharePoint to do some basic Web Front End (WFE) disk caching. We can tell SharePoint to pull certain resources from the database only on the first client request for that resource. The WFE will then take that resource and cache it to disk so that all subsequent requests for that resource get served up from disk cache rather than by making a full trip back to the database.

Okay! Lets enable Disk Caching!

Disk caching is not enabled by default and it's not an option available in the Central Admin. You'll need to edit the web.config file in the virtual directory of the Web Application you'd like to enable disk caching for...and you need to do that on each WFE you have in your farm. Below is an example path to a web.config file on a WFE server:


In that web.config file, search for the BlobCache settings line, it should look like the example shown below:

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

Change the tag properties to match your needs:

Location: this is the path to the cache directory where SharePoint will store cache files. You need to make sure the disk this directory lives on has plenty of storage, since the size of the cache is specified in gigabytes (see maxSize attribute).

Path: a regex to tell the caching engine what kind of files to cache. The match shown is by file extension, so if you wanted to cache .bmp files, you could change the path to : path="\. (gif||jpg|png|css|js|bmp)$"

MaxSize this is in GIGABYTES. The default is 10 gig. Remember, this is Web Application if you enable 10 sites to use the default caching scheme here, you'll potentially need 100gig of storage space just for disk caching (if the caches all happened to max out).

Enabled: just set this property to "true" to enable disk caching. The settings kick in on next page request after you save your changes to web.config.

..and thats all there is to WFE disk caching. Just enable it, change the setting as you need to and save the file. It might be a good idea to run a crawler over your entire site afterward to "pre-cache" your site resources.

That helped, but my site is still too slow. What now? more caching? Yes! In addition to disk caching of static resources, you can do in-memory caching of database content (called object caching in SharePoint speak). Unfortunately, I believe this is a MOSS only feature, so if you don't have MOSS you probably wont have the options I'll be talking about.

Okay, the options for object caching then show up in your site collection settings under (Site Actions->Site Settings->Modify All Site Settings). Under the Site Collection Administration heading, you'll find 3 links for administering caching settings:

  • Site Collection Object Cache

  • Site Collection Cache Profiles

  • Site Collection Output Cache

You'll want to enable Output Caching, but before you do be sure to review all the settings in all three of these pages to make sure the caching will work properly for your site. My times up for today, but I'll go into more detail about these caching options in a future article.


AutoSponge said...

Some of the slowness can be attributed to the site template used.

The normal OOB site templates create sites using files in the file system, and are therefore as fast as it gets.

The downloaded "fabulous 40" site templates are ALL stored in the database; which can hinder performance.

Also, if you brand your site with SPD instead of making a feature or file system-level file changes, your entire site gets sucked into the ContentDB as a version--and so does your performance.

Bryan said...

Thanks for the tip Paul!