Optimization is probably one of my favorite SharePoint topics – it seems there’s always a new trick to learn, and I love the fact that a minor tweak can have a dramatic impact on how well your site works. There are some great resources out there now for information on how to boost performance, but it strikes me that there isn’t one single paper or article which contains all the aspects I personally consider or have been relevant to me on past projects. Hence this article is essentially an aggregation of some of these sources. The aim isn’t for it to be “complete” (if there is such a thing) or authoritative in any way, and I know I wouldn’t be the first person to blog on this subject – it really is just a reminder list for me to refer to, but if it helps you also that’s great.
Key resources:
- How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance
- Optimizing Office SharePoint Server for WAN environments
- Prescriptive Guidance for SharePoint Server 2007 Web Content Management Sites
- Tune Web Server Performance (Office SharePoint Server)
- Many blog articles/presentations by AC, Spence and others
- Steve Souder’s (of Google) blog
Before I break into the list, remember that different optimization measures will have different effects depending on your circumstances - having the best checklist in the world is really no substitute for the SharePoint architect’s ability to identify what is likely to be the bottleneck for a given implementation. Additionally my list is quite “developer-focused”, but if the infrastructure aspects of the implementation is the limiting factor (e.g. latency between web servers and SQL, amount of usable RAM etc.) you can probably optimize code until you’re blue in the face without solving your performance problem.
My list is broken down into sections, and some of the items have links to some useful resource or other which you might find helpful if the topic is new to you.
Configuration
Items in this section typically have a big impact – in particular output caching, which is the first thing to consider on WCM sites for example.
- Output caching (or declarative caching at user control level)
- HTTP/IIS compression, including .aspx files
- BLOB caching
- Object caching configuration
- Is networking configured correctly e.g. cards set to gigabit
- Is search indexing configured appropriately e.g. consider dedicated WFE for indexing, crawl frequency/type
- Move CSS/JS files out of Style Library (to another library or to filesystem) due to HTTP 304s/BLOB cache bug
- Check using Fiddler/YSlow (more on this later) or similar for unexpected HTTP 304, 401, 404 codes
Code/development
- Test with SPDisposeCheck to ensure no memory leaks
- Measure page payload weight (again, YSlow useful here) – aim to reduce as far as possible
- Eliminate unnecessary ViewState! A good dev technique may be to turn off ViewState in web.config and then override it in controls/pages which really do need it (haven’t tried this, but keep meaning to).
- Ensure not downloading core.js etc for anonymous users/delay-loading for authenticated.
- Ensure image sizes are small/images are optimized for web (still comes up!)
- Always ensure height/width attributes specified on images
- Ensure custom CSS is factored correctly
- Don’t forget client-side code efficiency e.g. CSS, jQuery selectors
- Consider using a code-profiling tool such as ANTS profiler or dotTrace to identify sub-optimal code
- Ensure general good coding practice e.g. your optimization work may well be undone if your code is badly-written. Accidentally doing unnecessary processing in a loop (in server-side OR client-side code is one example I’ve seen many times)
- Be wary of performance impact of custom HTTP modules – I frequently see huge perf gains when running load tests with such modules enabled/disabled. Removing core.js as a post-processing step within a HTTP module is NOT the right approach kids! (No really, I’ve seen it done..)
Code/development – advanced
These tips might only really be necessary if you’re implementing a high-traffic site, but are worth considering:
- Consider factoring custom JS/CSS into fewer files – fewer HTTP requests is better
- Consider “minifying” JS
- Consider using CSS to cluster background images (all images stitched into one for fewer HTTP requests) – AC might have mentioned somewhere an online service to automate this..
Architecture
You should consider this section absolutely incomplete – hopefully there’s enough here to dissuade anybody of the notion that it’s only about code though! The first two in particular are key.
- 64-bit/sufficient available RAM etc.
- Latency between web and SQL – MS suggest a ping response of less than 1 millisecond
- Consider a CDN solution (e.g. Akamai, Limelight etc.) if users are geographically far away from servers (and y0ur client can afford it!)
- Ensure not using web garden with BLOB cache (known BLOB cache issue)
- Are app pool settings correct – check for excessive app pool recycling by enabling logging to the Windows event log using - cscript adsutil.vbs Set w3svc/AppPools/ <YourAppPoolName> /LogEventOnRecycle 255. Once or twice per day is probably the maximum you’re hoping for.
- Is storage correctly architected e.g. are OS, data, logs on different disk spindles?
- Is storage correctly configured (e.g. SAN configuration) – are your LUNS giving you sufficient IOPS?!
Using YSlow to help optimize websites
One particular tool worthy of discussion when we’re talking about optimizing websites is YSlow – if you haven’t come across it yet, this is a Firefox plugin which extends Firebug) developed by Yahoo! developers which uses their optimization ruleset (customizable) to report on and help further streamline your site. The tool focuses on communication between the server and browser – clearly a browser tool like this can’t identify any back-end issues, but it’s always interesting to run a site through the checks.
The first tab gives a ‘grade’ for your site based on the ruleset, helping you identify areas for improvement (I’ve highlighted where the page stops and the YSlow console starts with a red box):
The next tab provides a breakdown of files downloaded by the request, and allows me to see their size and headers etc. In particular I can see the expiry date and Etag and so on which the files are being tagged with so they can be cached locally:
The statistics tab provides some good analysis on the page weight and also illustrates the difference between a first visit and subsequent visits where appropriately tagged files will be served from the browser cache:
Finally the Net tab in Firebug is also interesting, as this shows me how files were downloaded (sequential or in parallel) – the most recent browsers do a much better job of this, with IE8 and FF3 being able to open 6 channels per URL domain to download files in parallel, but note that IE7 could only open 2.
From this, I also see the http://sharepoint.microsoft.com site (great site btw) I’ve been analyzing also displays the BLOB cache issue I discussed recently (now confirmed as a bug) where incorrect headers are added to files stored in the Style Library, causing lots of unnecessary HTTP 304s to go across the wire. So YSlow does give a great insight – however I do agree with Jeff Atwood’s reminder that some of the reported “issues” may not be the biggest concern for your site. As always, apply common sense.
Summary
Optimization is a deep topic, and this checklist is simply my reminder of some of the things to consider, though in reality a solid understanding of the nuts and bolts is required to really architect and develop high-performing sites. Tools like YSlow can also help with some aspects of optimization.
So which optimization nuggets did I miss which you consider? Feel free to leave a comment and add to this list..
