How to Scale a Web Solution (Part 1)

If you’re thinking about scaling your website/solution things must be going pretty well. But are they really? Before you scale a web solution, you need to pass a few sanity tests.

Scale or Optimise?

“The website is overloaded, we need more servers”

I’ve seen this more times than I can believe, and its a very common problem. Your website is encountering regular downtime, and you’re told it’s because the website is busy, TOO BUSY. 

Great, that should mean you’re making more money. Have you seen a marked increase in revenue? No? Hmmm, doesn’t sound right does it? Time to dig a little deeper and investigate some common issues

Who’s Visiting?

When was the last time your analysed your web traffic? It’s a good idea to see who’s knocking at your door because you never know when the big bad wolf could come knocking. 

Case in point. I worked on a website who used a 3rd party provider for one of their site functions. This was a “pay as you access” service. I.e. everytime you used their service you paid (in credits which you bought). Upon accessing the logs a group of about 10 IPs accounted for 90% of the API hits. Doesn’t sound right does it? 

I blocked the offending IPs and the load on the service dropped 90%. The cost savings to the business were considerable.

The same concept applies to your web traffic. Analyse where your visitors are coming from, and whether a common IP is hitting your site. It could be Amazon trying to price match you, it could be Google (agressively) scraping your site, or it could be a malicious bot out to cause trouble.

Check your web traffic for anomalies.  

Images

Check whether your images are being hotlinked. It’s far less common these days as bandwidth is cheap, but can cause unnecessary strain a server. 

Hot linking is when someone else uses your images, but links directly to your server (meaning you pay for serving their images). There are lots of ways to combat this, my favourite being a simple server modification that replaces all images with something telling visitors to come visit your site instead. 

Efficient Codebase

There’s no point scaling bad code. Of course there are limits to how much time you should spend optimising code, but a good dev will always know when/where there’s a bottleneck because you have a poorly constructed query or a poor piece of code. 

Don’t spend weeks of dev time to optimise the code for a 3% speed gain, but don’t throw money at it either. 

It’s a balancing act, but when you require a database server with 512Gb of RAM, you’ve got to ask yourself whether improvements could be made to the schemas or coding.

Check out products like New Relic to see where your codebase could do with some fine tuning.  

Infrastructure

Are you making use of helpful infrastructure (i.e. a CDN Content Delivery Network). This is a relatively easy, straightforward way to remove load directly from your servers. The idea is that your images are copied from your servers, and hosted with lots of other servers scattered around the world. These servers send the images to your customers leaving your servers with more time to do other things. 

if you’re not running any kind of CDN, think about putting one in BEFORE scaling up.  

Check for Bloat

How much data is being downloaded when your customers visit your page. This is a combination of the points above, but carries a very important distinction.

When I analyse websites, I check to see how large the overall data load is on a website. There’s no set limit to what you should be sending, but anything over 5Mb would raise eyebrows. 

I.e. bitmap images should not be used on a website and mobile menus should be lean and mean. 

Passed?

If you passed all of the above, it’s probably time to start looking at scaling up (or out). But as I’m sure you can see, there’s a lot to check before you do that. 

Checking all of the above is relatively quick and straightforward. It could save you thousands if not tens of thousands in wasted infrastructure costs.