Quite often, as web developers we are put under pressure by clients, bosses and managers to get the job done and to get the job done on time. Most of the time, we do. But then one day, you get that dreadful call, usually on a Saturday, while you’re just about to have a sip of hot cocoa and relax with a good book. You pick up (grudgingly) and it’s finally happened: It’s the client: the site is down.

“The site is down”, four words any self-respecting developer never wants to hear, yet it happens all to often.

In a previous life, before building a load testing service, before building karaoke software for the masses, I lived in Agencyland. Agencyland is quite the place, loads of clients, buzz, excitement and some really oddball types. It’s got parties and perks, and cool buzzwords and some really wicked offices. It has all the excitement and drama you could want as a young dev, but most of all, it has deadlines and budgets, and lots of the time, when these two things aren’t met, heads will roll.

It’s unfortunate when that happens, because in order to keep yourself sane while the clients are calling in the change requests, the project managers are heaping pressure on you to cut corners and the account director has just sold in that new feature that extends the scope – you tell yourself, “Keep calm, It’s just a website”. It sucks when it isn’t anymore, and it’s actually someone’s job.

I’m in no way trying to scare anyone here, so please take the above with a dramatic grain of salt. Yet it was these experiences that brought about my own interest in performance optimisation and load testing, and it was what eventually led to the creation of Loadzen.com.

This isn’t a post about that, it’s about the other thing – making sure you never hear those four dreadful words. Interestingly enough, there’s a lot that can be done to prevent them from ever passing your client’s lips, and it shouldn’t take any extra time to do the work.

So, after a preamble that’s probably a little too long, what can be done about a site being brought down by excessive traffic?

1. Is your database configured properly?

Yup, the number one reason things break is because your database has run out of connections and is refusing new ones. This happens a lot with WordPress sites and is one of the most common causes of failure. It’s quite easy to fix though. To Get MySQL to accept more connections (it defaults to 100), you could simply increase the limit on your host:


vi /etc/my.cnf
max_connections = 250

If you are using WordPress, enable connection pooling with this little trick, simply edit the file

wp-includes\wp-db.php

And replace this:


$this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, $new_link, $client_flags );

With this:


$this->dbh = mysql_pconnect( $this->dbhost, $this->dbuser, $this->;dbpassword, $client_flags );

And then this line:


$this->;dbh = @mysql_connect( $this->;dbhost, $this->;dbuser, $this->;dbpassword, $new_link, $client_flags

With this line:


$this->dbh = @mysql_pconnect( $this->dbhost, $this->dbuser, $this->dbpassword, $client_flags );

Note this will only work with PHP 5.4 or lower.

While we’re talking about databases – have you made sure it’s got enough memory? Here’s a tip – if you are hosting the site yourself on your own systems, then make sure you host the database on a separate (and high-RAM system).

If on the other hand you are using a hosting service that provides a database cluster – I’d strongly recommend you use the cluster as it’s less likely to fail than your custom setup.

This might be obvious to devs – but not all clients want to shell out for an extra database server, so picking a hosting provider with a database offering can someties be a boon for handling spikes.

2. Do you really need to dynamically load all that content?

You know what Google really likes? Fast sites. When you build your homepage template and it needs to hit the database ten times to get all of the various content elemetns, you are creating a significant processing and database bottleneck.

At Loadzen, we see that in almost 70% of tests run, the home page is the first thing that needs optimising. Single article or product pages are less expensive to render than that heavy, bloated home page that all your stakeholders have been clambering for.

What’s the solution? Caching.

Now you could go all out and install something like Varnish Cache or Memcached, but considering that realistically, you don’t have the time (or patience) to implement all that granular caching, there are other solutions you can consider.

I’m going to focus on WordPress here, but similar plugins exist for other CMS’.

The soluton here is to pre-render your site. So, for a cheap and cheerful solution – here’s the 4 steps you should follow:

  1. Sing up for Cloudflare and set up the DNS settings for the domain so that they pre-cache your content on their CDN
  2. Download and install the WP SuperCache plug-in.
  3. Set up according to the recommended settings on the plugin page
  4. Relax.

WP SuperCache is very handy, and in many ways superior to it’s cousin W3 Total Cache because it’s a easier to get started with and serves it’s purpose well.

If you don’t know it yet – Cloudflare is an incredibly useful service that will not only protect you from Denial of Service attacks, but also pre-cache your content on their content delivery network and deliver it dynamically to users for you, without you having to lift a finger.

3. Sniff out the slow functions

You know the ones – those odd bits of functionality – hacks – that have been put in place to get the job done, usually involving gratuitous usage of for loops and giant hashmaps.

These need to be weeded out and destroyed, because at some point, they will be your undoing. The worst offenders here are usually sitemap builders, anything that is recursive and search functions.

Keep an eye on these, because they can become the thing that breaks everything.

I guess this is a very generic rule, and is akin to saying “Don’t write sh*t code“, but in this case what I’m trying to say is, we all sometimes write crummy code. These snippets are our slightly wild and badly-behaved offspring, and just like babysitting your neighbours’ weird kid, you need to keep an eye on them, just in case they get into the good china and start breaking stuff.

It’s OK to write hacky code, it’s not okay to forget that you wrote it!

That about settles it, there you have the three most popular reasons for a client screaming at you (or the account director, who will then transfer the verbal abuse kicking in domino fashion down the chain of command).

And you know what, if you really are worried, and you have a bit of time? Jump onto Loadzen.com and run a quick load test to put your mind at ease.

What obvious reasons have you encountered when building a website and hearing “The site is down?”, have we missed one?