The Object of My Cache

In the first post on caching I explained the output cache and how it can speed up your MOSS site. In this post I will explain the object cache. This cache comes ready to use in MOSS by default and does not require much tweaking except for the size of the cache.

Since MOSS uses SQL Server to store all the content of a site, it can get pretty expensive to make round trips to the database for each piece of content, so MOSS stores the most used objects such as document library and list fields and site navigation on the disk. This caching is very granular and is less expensive over time.

As the site administrator you can adjust the maximum disk size alloted for the object cache. The default is 100MB per site collection. In order to find the right size for this cache you will need to monitor the Sharepoint Publishing Cache in performance monitor. Keep an eye on the publishing cache hit ratio, and the total object discards counters to give you an idea of how you should adjust the cache size.

To change the size of the cache:

1. Click site actions->site settings->modify all site settings

2. Click Site Collection Object Cache

3. Change the value of Max. Cache Size and click OK.

One thing to keep in mind when using all of the different caches is that they all share the same virtual memory within the process. If you set the object cache really high that leaves less memory available for the other types of caching. If you are running on a 32-bit operating system then the W3WP process has a maximum limit of 2GB to use for the application. This 2GB also includes the space alloted to dll's and modules loaded by MOSS. A good rule of thumb for the object cache is to start at 200MB and increase it until the hit ratio is low high (< 85%). You can also test the cache by hitting the pages and seeing the response time for a user.

In the next post I will cover disk-based (BLOB) caching.

Output Caching

In the next three posts or so I will be covering the types of caching available in ASP.Net 2.0 and MOSS. The first of these three types is output caching. Output caching is the ability to render a page once and then store the HTML output of that page in cache for a set period of time. Each user (and I use this term fairly loosely for caching; I will explain in a little bit) that hits the page after it is cached will receive the cached page. The output cache caches a page based on type of user, either authenticated or anonymous, and by the type of browser. Yes, out caching stores each page for each browser type, so the Mozilla rendering of a page will be separate than the IE rendering.

This type of output saves both on processor speed and the number of round trips to the database which can be pretty slow depending on your MOSS configuration.

Thus type of caching is only available if you have the MOSS Publishing Infrastructure feature enabled. If your site is built on the Publishing Portal or Collaboration Portal then you have this by default.

Go to Site Actions - Site Settings - All Site Settings and go to Cache Profiles to set up the profile and its settings. You can have profiles for different types of users, one for anonymous, or one for authenticated users.

You need to give the profile a title and you can give it a display name and description. You can then check the checkbox for Performa ACL check. This will check for security trimming when caching. If you do not need security trimming then uncheck the box to increase performance.

You then need to check the box labeled Enabled to enable the caching on that profile. This check box allows you to easily trouble shoot a profile by enabling and disabling in one click.

You then set the duration to hold the cached pages before re-rendering the page. This number is in seconds. A good rule of thumb is to start at about 2 hours and check the performance of your server and adjust the cache duration accordingly.

The Check for Changes box if checked will check to see if the page has been changed. If it has it will re-render the page and store it in the cache. If the page has not changed then the cache will be used. If you check this box it will decrease performance as the site now has to check each page for changes before it renders the page.

You can then choose to vary the cache profile based on custom parameters, HTTP headers, query string parameters, or User rights. For most people you can leave the defaults that come with the base profiles.

Cacheability defines where the page gets cached and is one of the following: none - the page is not cached, server - the page is cached on the server, private - the page is cached in the browser, server and private - the page is cached at both the server and the browser.

The last two check boxes allow for caching for authenticated users and for contributors.

After you have created the profile you then need to enable the caching and select which profile to use for both anonymous users and authenticated users. There are also some check boxes on this page to allow sub-sites and page layouts to override the caching of the rest of the site. This can come in handy if there are a couple of pages that render code differently depending on a selection. You may need to turn caching off on that page layout for the page to render correctly.

You can also enable debugging information in the pages. This is handy to test whether pages are staying in the cache and to make sure they are staying in there for the entire duration time. This will place a timestamp on the very last line of the HTML source that will give you the profile that rendered the cached page and what time and date the page was cached.

Caching requires a lot of fine tuning for performance of your server or server farm. Dedicate the time, though, and your site will run smoothly and scale easily.

Here is a wonderful article on performance tuning and caching that will aid you on your journey:

http://blogs.msdn.com/ecm/archive/2006/11/08/how-to-make-your-moss-2007-web-site-faster-with-caching.aspx

In the next post I will explain object caching and how to track it.

When a Cache is Not a Cache

The first problem area I had with our project was when we made the Internet-facing site live. We set up output caching and BLOB caching to cache pretty much all of the site. We also setup the Object cache. We figured we had our bases covered because we tried these things on our development site and they increased page load time significantly.

The site went live and it was doing well for most of the morning when 11 o'clock hit and we now had 3 time zones worth of people hitting the site. We suddenly noticed that the processor was getting pegged at 100% and that the amount of memory used was increasing quite quickly.

After spending a week looking at the performance monitor for various counters and checking Microsoft documentation, we had finally figured out that some of the memory leak was due to not cleaning up SPRequest objects. We cleaned up all of our custom code and this improved the site marginally. We also began tweaking the output cache to find a good balance and settled on 4 hours for pages to be cached. The BLOB cache works wonderfully, it caches images, and other Binary Large Objects. It is awesome to see whole pages load without images filtering in one at a time.

The site was still not running quite right and we had noticed on the object cache counter that objects were being thrown out of the cache as soon as they were put in. I began monitoring the SharePoint logs and found that pages were being invalidated and thrown out of the cache. So this led to a call to Microsoft. After the same questions and sending them an SPSReports CAB file, they came back saying that the object cache does not cache custom code objects. This didn't fare well as almost every page of our site has custom code on it. After looking over the options and Microsoft telling me that there was no expected date for a fix, we decided to monitor the site some more and noticed that the page output was still being cached, so the object caching not storing our code was only going to be a problem for the first person to hit that page. We decided that this was acceptable performance for the site.

In the next few blog posts I will explain the various types of caching and how they can help your MOSS site's performance and scalability (especially if an Internet-facing site).

Can I assist you?

Over the last few months I have been supporting the MOSS installation of an Internet facing site that I had been creating for a client over the last 6 months or so. With the support comes finding issues in code, performance, and other areas. One of these areas could be classified as interesting things about the SharePoint code itself.

I have been on the phone twice with Microsoft support for various issues and both times the tech has asked the same questions about the MOSS installation and any error messages that I had encountered. Then they usually ask me to install SPSReports from the CodePlex site, http://www.codeplex.com/spsreport. This tool gathers information from all of the system logs, the SharePoint logs, the registry, 12 hive, and various other areas. It compiles it into a CAB file that you can send to Microsoft so they can replicate your MOSS configuration on their end and figure out what the issue is.

If you plan on doing any customizations at all on MOSS or WSS then you may want to have this program installed on your development server, so when the time comes you are prepared to bundle up the file and send it to Microsoft.

The next few posts will be some of the many issues I have run across over the last couple months with MOSS.