Wednesday 30 September 2009

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.

webpagetest waterfall and optimisation

I’m impressed!

Thursday 24 September 2009

Removing the shutdown details prompt in Windows Server

If you’re anything like me, chances are you’ve got dozens of virtualised dev servers hanging around and you shut them off at the end of the day; you also have no idea what to put in the Shutdown Event Tracker Comment box. The event and comment do get written to the event log for future reference so I usually comply and specify an exact reason where applicable or with my standard comment “a” for “all good” or “a-team” or something like that!

In practice, I’m the only one using my dev environments and I’ve never had the need to remind myself why I shut down the server. The specific event is likely buried among the shut down/start up events anyway and it’s probably safe to say this feature was intended for multi-admin production environments.

The shutdown event tracker is just an extra hassle as a developer but it can be turned off:

  • Run –> gpedit.msc
  • Browse to the Local Computer Policy / Computer Configuration / Administrative Templates / System node
  • Locate and open the Display Shutdown Event Tracker policy
  • Set it to Disabled

Life = that little bit easier.