Simon Miller Team : Web Development

This blog cost five dollars aka The Load Impact Blog

Simon Miller Team : Web Development

Today was the day that stopped the nation (but mainly Melbourne, who got to join in on the festivities… or just sit at home on the Xbox). Casual punters Australia wide took time out today to drink a beer, yell loudly at a television screen in support of a horse that until 11am they didn’t know existed, and otherwise pretend to have amazing systems guaranteed to score them a winning trifecta. Offices everywhere allocate a random pony from the Sydney Morning Herald race guide to willing staff members who pay five bucks for the privilege to hopefully win from an office pool.

As with all competitions there are winners, and then there are losers. My allocated horse “Verema” fell at 2000m and is currently on the way to the Whiskas factory (jokes… or is it?). The rules of our office pool were simple; prizes for 1st, 2nd and 3rd placings with the last place “winner” having to write a blog. So, here it is.

Today is a good example on why load testing your site can be important, as well as preparing for large scale load impact. Millions of people right now are currently searching “melbourne cup last place” into Google. God help any of the links that come up in those results, as they are about to get slammed. There are a few simple things to do with a website to prepare:

 

1. Optimise your website

Optimise your website, focusing on two important things first – the ‘time to first byte’ and the speed in which your media (i.e. images) are served.

The time to first byte is the time it takes for the server to process the request and begin serving the page. Ideally this should be less than 50ms. Depending on your site complexity this can be 300ms. If you ever take over a second, you are doing something very wrong. Whilst seasoned developers will always state that ‘caching is a crutch’, it is still valuable to cache frequently accessed data to memory, as memory is always faster than the database. There can be many other factors that can cause a slow time to first byte as well, from the need to optimise some of your code to selecting a host that is closer geographically to your main user base (there is no point hosting cheaply in the US if your website only ships products to Australia – is it really worth the 300-500ms delay?).

To increase the speed of your media, ship your images off to the cloud. If you have lots of product images, it may pay to have them hosted on a service such as Amazon S3 or Windows Azure. Corporations this massive have infrastructure for rent that never goes down, and through distribution and caching techniques are significantly faster than serving files from your local host. Plus, the removal of a substantial amount of traffic from your host to the cloud will also speed up your website.

One other trick you can do (which is good practice anyway) is to ensure that your CSS and JavaScript are minified and served in less files via bundling. Browsers can only connect to a limited amount of sessions at the one time, so you may as well not waste those on redundant scripts. Microsoft has a good article on bundling your CSS and scripts into fewer files for .NET projects.

 

2. Check your website

Check your site against a tool such as Load Impact. For a small fee (and it really is quite small in the grand scheme of things), Load Impact will run different types of tests against your website designed to gague how many users it can concurrently sustain before causing errors. Load can be distributed from different geographical locations for broader testing, can be scheduled to run at whatever time of day you need and most importantly, the service provides powerful reporting to help you improve your results for next time.

 

3. Tell your hosting provider

If you have fore-warning that a large amount of traffic is heading your way (for example, you are about to email your entire user base a discount coupon too generous to ignore), let your hosting provider know before you send it! On the right setup (such as multiple front-end VPS and clustered SQL), you can pre-arrange for your provider to add extra nodes to cope with increased load. This won’t be free, but you may weigh up the cost of extra temporary services versus the cost of losing business and choose in favour of planning ahead.

 

UPDATE:

It appears that as my horse “Verema” fell early it technically did not come last. That prize goes to the horse “Ruscello”, meaning, I didn’t actually need to write this blog. Still, I hope these tips are useful to somebody!