Enable gzip compression with GoDaddy Linux Hosting (Apache)

GoDaddy’s documentation claims to have mod_Deflate installed by default on all but its Classic Hosting accounts but any basic HTTP sniffer (YSlow or Fiddler) suggests text-based resources like Javascript, CSS, XML, etc aren’t being compressed. Google’s Web Master Tools will likely flag this to you as well and you can use an online tool like redbot.org to inspect your headers.

If you’re not seeing a header like this one, your content is likely not being encoded:

Content-Encoding: gzip

To enable compression on one of the site’s I’m working on, I added this line to the bottom of the .htaccess file at the root of my site:

AddOutputFilterByType DEFLATE text/text text/html 
text/plain text/xml text/css application/x-javascript 
application/javascript

Bear in mind compression is only one aspect of a performant site. Among other things, you’ll also want to ensure your content is cacheable for a suitable length of time. Consider combining and minifying your CSS and Javascript and use a free content delivery network (CDN) like CloudFlare to accelerate the local delivery of your image assets.

If you’re really keen (or suffering performance problems) consider using image sprites to reduce the number of resources a page needs to download and move away from server-side code where you can. The vast majority of your page content is likely static (even if it’s being generated dynamically—but isn’t personalised) and should be cacheable at the browser level.

YSlow Configuration “Use a Content Delivery Network (CDN)”

The westernaustralia.com site is served to users all over the world from the most remote city in the world: Perth, Western Australia. In other words, we target users in core markets across Australasia, Europe, and North America and while we expect a consistent homepage load time below ten seconds in all cases, Perth to New York, Perth to London, and, really, Perth to anywhere equates to high latency, congestion, and poor response times. Couple that with SharePoint, a rich, interactive site design, and an excessive number of page requests and you'll begin to appreciate why we chose to serve the site across Akamai's content delivery network.

I'll describe the setup in detail someday but for now, I've finally managed to convince YSlow the site is being served using a CDN; while we use better tools for global performance measurement (Gomez), seeing a low grade—in part because the hundred-odd requests were perceived to be served without a CDN—was starting to get me down ;) YSlow is a great plugin for analysing your site in Firebug but it's grading system can be a bit tough.

The YSlow FAQ will tell you how to configure the plugin to acknowledge the use of a CDN by setting a extensions.yslow.cdnHostnames preference. I won't repeat those details here but will expand on how the string value might be configured to tell YSlow a CDN is in use—whether you’re telling the truth or not. It’s surprisingly simple.

In our particular case, www.westernaustralia.com is a CNAME to an Akamai URL so telling YSlow to use akamai.com as a CDN doesn’t make sense and YSlow isn’t smart enough to figure things out on its own. Since www.westernaustralia.com is implicitly its own CDN, configuring the the extensions.yslow.cdnHostnames value as westernaustralia.com sorts everything out. I had to restart Firefox (3.5.x) and reload the page for things to take effect.

If you’re not using a CDN and want to turn off this particular component of your grade (or at least make it an “A”), simply add your own URL; regardless of whether you’re actually using a CDN, YSlow will think you are.

Web site performance monitoring tools

Having gone through the pains of learning about web site performance and applying that understanding to a MOSS site (www.westernaustralia.com), the latest post on the SharePoint Team Blog about optimising sharepoint.microsoft.com caught my eye. I’ve been meaning to cover the performance nitty gritty from our experience for ages now but, for the moment, suffice it to say we fixed most of the problems faced by our global audience and now use a commercial performance monitoring service called Gomez to keep an eye on things. Gomez competes with the likes of Keynote if you’re in the market.

Commercial solutions like this cost a lot of money because they’re essentially distributing test agents all around the world and measuring full page load times from your site at a configurable interval. Response metrics are stored for trending analysis and comparison with other sites. Despite the cost, these tools are worth the money if you know your site is experiencing performance issues (if not the data gets boring really fast).

Firebug, YSlow, and Fiddler are great tools for analysing performance and will give you both page load time and page weight but they’re all executing from your desk; if your web server is down the hall or in the same city (or country) you may not have a clear picture of how latency is affecting your site users on the other side of the world. If you’re targeting a domestic audience that’s obviously not a problem but if you’re targeting a global user base and you’re attempting to do so with SharePoint you need to ensure everything about your site is optimised—not just just the server configuration. The SharePoint Team Blog post highlights the fact SharePoint (MOSS 2007) is not optimised for internet sites out of the box.

As the cost of these performance measurement services is prohibitive—especially in this tough economy, it’s interesting to see where the free services are going feature-wise. I mention the SharePoint Team Blog post specifically because the author cites a new tool I hadn’t yet come across: http://www.webpagetest.org/ I’ve previously evaluated Pingdom but their offering was still developing a year ago (they offer both free and paid services).

The webpagetest.org site is painful on the eyes but the data they provide at no cost is comprehensive. The site currently allows you run tests from one of three nodes (the US, UK, and New Zealand), meaning an adequate global coverage (we test westernaustralia.com from seven locations matching the site’s target markets).

The tool reports the results from a full page test, meaning the page and all of it’s supporting resources are requested, providing a realistic picture of how long it takes to load the page and all CSS/Javascript/images/XML files/Flash files/etc. Some of the freebie offering I’ve seen in the past only reported the page HTML load time, which will often be negligible.

In addition to giving you a screenshot of the page, which is often useful to compare what the world sees versus what you think they’re seeing, you get full waterfalls of data for a first visit and what they call a repeat view (a subsequent request for the same page with a primed browser cache), and an item by item optimisation checklist.

I’m impressed!

YSlow for Firefox 3.5 Lives?

YSlow has been the tool for measuring page payload and providing the metrics you need to optimise web site performance beyond the web server. Shock horror when I recently upgraded Firefox to version 3.5 and couldn’t install YSlow.

Initial rumours confirmed the current version of YSlow doesn’t work with FF3.5 but also suggested development by Yahoo! had ceased. Meanwhile Google launched Page Speed—a likeable YSlow competitor (maybe?).

A recent posting from a Yahoo! dev would suggest YSlow will actually be updated but “the team has run into some integration issues with firebug 1.4.” If you want to install FF 3.x and 3.5 side-by-side, check out this guy’s article.

SharePoint and SQL Server with Greg Low at PSPUG

Sezai’s been doing a fantastic job of attracting some high-end speakers to the Perth SharePoint User Group and we had the immense pleasure of attending Greg Low‘s presentation on SQL Server optimisation for SharePoint admins this month.

Greg is a god among men in my mind and one of those can’t-miss speakers; apart from being a SQL Server MVP and Microsoft Regional Director, he really knows his stuff and delivers a nuanced presentation. I’d seen Greg in Adelaide on previous occasions and since he’d made his way all the way to Perth just for us, there’s no way I’d miss him.

There were some key take-aways from Greg’s talk I’m paraphrasing here for future reference… note I’m not a DBA and don’t necessary understand all of this—in other words, don’t apply this advice blindly without additional research!

• The autogrow settings should be configured appropriately on both content databases and the tempdb—the SQL Server defaults are inappropriate. In general, this means turning off autogrow and managing database file size manually. Alternatively, autogrow can be left enabled for contingency but should be reconfigured to grow using an appropriate value (in MB, by ~100MB).
• tempdb is rebuilt to the configured autogrow value every time the sqlserver process restarts; the start value should be large enough to avoid file system fragmentation.
• Never, ever auto shrink a SharePoint database as it will only have to regrow again and may increase fragmentation.
• Use DBCC CHECKDB but beware fixing problems may incur data loss.
• Whack your disk subsystem using benchmarking utilities like SQLIO and Iometer. Reasonable latency falls between 5-15ms, for example.
• Instant file initialisation allows SQL to write to files that have not been zeroed out by the OS, thereby avoiding the performance hit incurred by that activity. The MSSQLSERVER service account must be granted the SE_MANAGE_VOLUME_NAME right by virtue of being added to the Perform Volume Maintenance Tasks security policy.
• Multiple HBAs can lead to write ordering and disk subsystem issues; SQL Server 2005 introduced page checksums to help with this issue but the feature is turned off by default; it should be enabled.
• Virtualising database servers faced a lot of bad press in the past but those days are behind us. Hyper-V R2 and ESX are the way forward.
• Don’t even think about SQL Server 2000.
• The gap between SQL Standard and Enterprise is getting wider with SQL Server 2008.
• As most SQL Server instances are disk and memory-bound, consider enabling table/row/page compression in 2008 to reduce IO and memory usage at the expense of CPU. You mileage may vary as this will obviously depend on the content to be stored as photos and Office documents are already compressed. Backup compression is also possible.
• Configure databases with one file per CPU core.
• Different databases have different IO profiles; tempdb should be hosted on a dedicated spindle (see http://technet.microsoft.com/en-us/library/cc262731.aspx for more info about locating the various SharePoint databases).
• Ensure statistics are configured correctly.
• Index fill factor should typically be ~70% for a typical SharePoint environment.
• The default Windows Server 2003 sector size is too small; set it to 64k when formatting drives.
• Clustering SQL won’t boost performance like mirroring will. Clustering happens at the server level whereas mirroring must be configured for every database.
• If configuring a SQL alias, use TCP/IP.
• Create a separate SQL Server instance if an existing database server’s collation doesn’t match SharePoint’s specific requirements. Changing an incorrect collation is a lot of work.

SharePoint on SharePoint – Under the Hood

The SharePoint Team Blog just announced they’ve launched the www.microsoft.com/sharepoint site on SharePoint itself with a large sprinkling of Silverlight. The post mentions the use of the publishing feature and SEO optimisation so I thought it would be interesting to see if I could find any really cool, secret WCM optimisations. I’m disappointed and can’t suggest modelling your own internet-facing MOSS site on this site :-(

• Looking at the site URL alone I can tell this is a MOSS site: /pages/default.aspx. I was hoping to see the /pages directory magically vamoosed from the URL and I’d hardly say Default.aspx is SEO-friendly.
• The total page weight, according to YSlow, is 538.5KB, which translates into a load time of 13.81s from Western Australia and a grade of F (despite waiting for the Silverlight banner to load the page load time didn’t feel too bad but reloading with an unprimed browser cache was sluggish but I have little doubt they’re running off a CDN)
• The JavaScript and CSS aren’t minified and both init.js and core.css are loaded in their entirety.
• The number of resources requested by the page is significant and there’s been no apparent effort to merge CSS and JS files
• The page viewstate equates to 62KB of the overall page weight while another 68KB pertains to inline Silverlight load script stuff

The single neat-o thing about this site (let’s say apart from its content and this is a technical blog) is the way hitting the Login link or trying to hit /_layouts/settings.aspx redirect to the Live login form. It would be interesting to know if they’re actually using Passport authentication on this site.

Sharepoint Administration Toolkit 3.0 and spdiag now available

The Sharepoint Administration Toolkit 3.0 is now available in 32-bit and 64-bit flavours. This release add the Sharepoint Diagnostics Tool (spdiag) for collecting performance stats from disparate sources and helping out with the troubleshooting process. An spdiag user guide has also been made available.

---

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Conent Delivery Network (CDN) Alternatives

If you're looking to deliver your website via a content delivery network or content distribution network like Akamai, Limelight, or CDNetworks, you've got a few alternatives to consider (especially on the cost point). 

• Amazon is set to release a new pay-as-you-go content delivery service before the end of the year. It's also built to integrate with Amazone S3 for storage. 
• Coral is a free CDN built on peer-to-peer technologies. Seems like it's being run as some sort of test project but it's free.

In case you're interested, www.westernaustralia.com has been delivered through Akamai since early August. We reduced international load times from an average of 43.5 seconds to 5.5 seconds on go-live but pay a hefty annual fee for the privilege. We're using their standard geographic caching service and their Dynamic Site Accellerator product to speed up requests that do have to hit our Perth-based servers.

Tokyo Performance

I'm on a month-long holiday back home at the moment (Australia -> Canada) so I shouldn't even be thinking about MOSS and work but nonetheless I am. This is day one into my time off and since I'm waiting in the North West Airlines lounge in Narita airport in Tokyo at the moment, I really don't have anything better to do (laptop left at home...). Specifically, I'm thinking performance.

In previous posts I've alluded to the performance issues we're addressing across the MOSS 2007 sites we maintain (www.westernaustralia.com, www.tourism.wa.gov.au, and www.australiasnorthwest.com with more to come before the end of the year). We've done a hell of a lot of work over the last few months to bring our page load times in line with internet "standards" (say, less than ten seconds) following continuing internal allegations the www.westernaustralia.com site was slow to load. 

The focus to date has been on reducing the number of requests it takes to load the home page (we started around 130 if you're viewing the site internationally and we're now down to 70 or 80), as well as trimming weight, and optimising our server environment. We use Gomez to measure relative page load times from various locations around the world and the results indicate latency causes huge problems for our sites. The wa.com site was designed to be "visually interactive" and by default as a tourism site it has to pop. Although a Sydney-based design firm did the graphic design, we had no requirements relating to performance apart from a useless mention to do with broadband users. Anyway, we've been testing the site through Gomez every hour since May and our global average home page load time started off somewhere around 44 seconds with spikes to 120 seconds in some regions. Ouch. By reducing requests, making sure a reasonable cache and compression policy was implemented, and doing the basics like reviewing image compression, we got load times down to the 36 mark before the asw.com site launched and started caning the shared database server. We've also signed up with Akamai (a content delivery network) and that should be live sometime next week.

So that's the background. And here I am in Tokyo loading the home page from a cold cache at around 2:30pm on a Saturday. Database issues aside, the page was useable and just about fully loaded by the 18-20 second mark. Japan has some amazingly fast connections and as Perth has a massive connection to Singapore I suppose it's possible my request was routed more or less directly across some fancy infrastructure. I know the site, of course, but my perception was it loaded in a reasonable timeframe. We're off from Tokyo in a few seconds to the US and then Canada so it will be very interesting to see whether the performance I just experienced is either Japan-specific or Saturday-specific (traditionally a busy time on our servers). 

Google Analytics vs Omniture

We use Omniture's Site Catalyst tools for web site analytics across www.westernaustralia.com and all of the connected Tourism Western Australia eMarketplace sites. There's been a mad rush on stats lately, initiated by the CEO, so I've been waist deep in Omniture stats coming to terms with an area of web development to which I've never paid much attention.

Omniture costs money and until the other day I was under the impression Google Analytics was a paid service as well. Silly me. Until now I've been displaying AdSense ads on this blog to get a rough idea of page views and not a lot else. You may have noticed I don't care much for AdSense.

I finally decided to have a look at Analytics and after realising it is a free service I signed up. Much to my suprise, the stats available are very comprehensive and while I imagine Analytics is taregetting a different group of sites than Omniture, I'm struggling to see many advantages to going with an Omniture solution. Customisation would be a biggie and I've heard Analytics stats are big shonky at times, which is kind of important ;-)

Analytics is now live on this blog via a simple bit of JS and I'm dying to know how you're arriving here and how often you return. It's all fascinating stuff and I've been watching my "readership" increase slowly but surely over the last year so some additional detail will be welcome.

Make 'Exires' Go Away

Yesterday I posted about the useless 'Exires' [sic] header moss emits with content served from the content database under the default configuration. "Shame on you MOSS!" was shouted with just cause.

Nevertheless, I've found a fairly easy way to make 'Exires' go away and configure MOSS to emit better cache headers. It's pretty simple and while it will cost you a bit of disk space it should also save on roundtrips to the database server... all you need to do is enable the MOSS BLOB cache (aka Disk Cache).

The BLOB cache is turned off by default (for some reason) but when enabled it'll grab a copy of content database resources on the first request and cache them on disk for faster access down the road. Not only that, but, despite the name, the BLOB cache makes MOSS smart enough to emit good Cache-Control headers with your content.

The BLOB cache is configured through the web.config at the web application level, which leads me to believe you won't be able to set different max-age values for different types of content or different content groupings (let's say you want your .css and .js files cached with a different max-age value--or none at all--from the served with your images). If you're used to doing this with the content expiration mechanism in IIS at the folder or item level you may be out of luck here.

Enabling the BLOB Cache is ridiculously easy. Dig into your site's web config and find the BlobCache element (you'll need to do this on all related sites--i.e. anonymous and authenticated if you're running both on the same server). Set the enabled attribute to "true" and you're set. You may additionally want to modify the location where MOSS stores the BLOB data (i.e. a non-system disk), add extra file types to those already configured, and add a max-age="3600" attribute. The max-age attribute will be included with the Cache-Control header and is defined in seconds. Be careful with this one because if you set it to too large a value, your content will cached for the entire duration unless users clear their browser caches. Finally, the maxSize attribute defines the maximum size of the BLOB cache in gigabytes.

<BlobCache location="D:\MOSS\Cache\Consumer" path="\.(gifjpgpngswfcssjs)$" maxSize="1" max-age="3600" enabled="true" />

MOSS instruments the BLOB cache using performance counters you can access in Performance Monitor to determine cache health, turnover, etc.

If you get the BLOB cache working you should also consider reviewing the MOSS Output Cache. I'll save the details for another post but this cache extends ASP.NET output caching and deals solely with page content.

yslow for Performance Measurement

We're doing a fairly thorough performance/load time analysis of westernaustralia.com at the moment and I was recently introduced to YSlow in the process. YSlow originated at Yahoo! and works as a Firebug-dependent Firefox add-on.

In addition to using a combination of packet sniffing and DOM sniffing techniques to give you an accurate idea of how long the current web page takes to load, it also reports page weight, gives you information about page load weight from a primed and unprimed browser cache, tells you all about what's got an Expires header, what's got an etag, what's being gzipped, allows you inspect page components directly or at the header level, and grades the page overall. The grading system is backed up by a thorough set of recommendation for increasing the grade.

Apparently YSlow even fixes a bug with the Firebug net pane!

Definitely enough for me to add this to my toolkit--thanks Yahoo!