Web App for Scalability

7/27/2019 Web App for Scalability

1/9

Skip to content

Follow:

RSS

Twitter

Mr Kirkland

Your all singing and breakdancing CEO

Home

About

Contact

Tags

application, mysql, scalability

by Mr Kirkland on May 11th, 2010

Congratulations, your server is melting.

This is a good problem to have (server heat is proportional to # of users). And its not so difficult to deal with

if make a few preparations in advance.

After launching a number ofweb services and viralsocial mediaapps, some of which grew to hundreds of

concurrent users and zillions of hits within days, Ive had to learn on the job about scaling websites. Here I

present to you my thoughts and some simple suggestions on how you can prepare ahead of time.

Really the most important principal to take on board is modular design. If you look at any high volume

platform youll quickly see evidence of how the components of the service are split up into separate

independent units. Wikipedia is classic example of this, cheek out the architecture behind wikipedia.

If you can separate all the different components of your website/web app, then you can easily apply more

resources where they are needed. Just upgrading to a bigger server wont get you far, long term you need tobe able to identify where the bottle necks are and apply resources efficiently. In fact even identifying the

bottlenecks can be surprisingly hard, modular design makes this much easier.

ring Your Website/Web App For Scalability http://www.mrkirkland.com/prepare-for-web-application-sc

1 1/24/2012 1


2/9

Spilt services into independent modules, its much more efficient to scale them individually

So some examples of the typical components your website/web app will be using:

media, images, static files (javascript, css etc)

db server

mail

batch processing (webstats, image resizing etc.)

front end (normal user area)

back end (control panel)

Separating these components neednt be rocket science, heres some simple examples of how you could apply

modularity to the components above:

media -> move all media and static files on a dedicated domain/subdomain (or better still in a

CDN) e.g.

db server -> always use a central config file for db settings, so you can easily change the hostname

when the time comes to use a dedicated db server: $db_hostname = mydomain.com ->

$db_hostname = dbserver.mydomain.com;

mail -> again make sure mail settings are in a central config and ideally use a framework/library thatallows you to change to an external SMTP server/service

batch processing -> create an independent system for any batch processes, for example use a

standalone phpthumb installation for image resizing.

separate front end / back end -> make use of different a domain for control panels

e.g. www.mydomain.com and controlpanel.mydomain.com, so later on itll be easy to move these onto

different servers

In addition to thinking modular, always be monitoring and profiling your systems then you know exactly

where the bottlenecks are and can deal with them more effectively.


1 1/24/2012 1


3/9

1. Queuing/Batching

Queuing prevents a server being overloaded all of a sudden

Typically there may be parts of your application that involve heavy processing. If these dont need to be real

time, or can tolerate slight delays then separate the processes and make use of queuing/batching so your web

application isnt held up.

Google Analytics is a good example of this, generally theres no need to have real time webstats, so the

collected stats are batch processed at regular intervals. Another example could be image processing, Ive

written about this in more detail here.

2. Partitioning

Taking modularization a step further and we have partitioning i.e. splitting data up in to smaller manageable

chunks which can be stored/operated on separately. If you have a multi user system you could split users

across servers, so for example your could have 1000 users per server, or split users by user id odd/even,

divisible by X etc. Again you could do this ahead of time with subdomains:


1 1/24/2012 1


4/9

odd user i d: cont r ol panel - a. mydomai n. com

even user i d: cont r ol panel - b. mydomai n. com

Another example of partitioning is database partitioning, heres a quick introduction, but this would come

way later, having a dedicated db server or db cluster will scale you a long way.

3. Code First, Profile and Optimize Later

Slightly contrary to the idea of scalability, but definitely on topic: dont start your code design with

optimization, this is a waste of time. Not even the mighty He-man could predict where all your bottle necks

will be. Always focus on writing easily maintainable code, and then in the later stages of development you

can profile your application to find out where you need to optimize your code.

4. Cache Cache Cache

Caching is probably the simplest and cheapest way to dramatically improving performance. There are a

variety of stages at which you can use a cache and whilst some require a little care at least a couple are almost

trivially easy to implement. Its good to be aware of all the options even if you dont need to implement them

yet.

Super Easy

Opcode Cache/Acceleration (like APC, xcache) -> once installed require minimal maintenance and are

completely transparent to your application. They simply keep copies of your complied scripts in

memory.

DB Cache -> again usually very simple to install and will be transparent to your application and keep

the result of queries in memory. for mysql users, see here.

Easyish

Cache server/HTTP accelerator (squidnginxvarnish etc.) -> This is very common with high traffic

sites, Caches can easily multiply the capacity of your website. Again this kind of cache is outside of

your application so is relatively easy to work with. However you may need to take some precautions to

ensure certain items arent cached, and are expired in good time and youll need a higher level of

sysadmin skills to set up and maintain a cache server.

Built in framework cache -> many code frame works come with a cache system out of the box (e.g.

codeigniter) this is a lot easier than rolling your own, but still youll need to be aware of how it works

to avoid caching pages that should stay fresh.

Harder

Application object cache -> this kind of solution involves using a library/framework that allows you to

cache arbitrary objects/variables across sessions. For example you might have a widget that appears on

multiple pages, you could cache the object that generates this widget (or even the HTML output itself).

Setting HTTP headers -> you can of course manually set HTTP headers that tell web browsers how

long to cache pages for. This gives the best performance boost as the data is stored locally on the end


1 1/24/2012 1


5/9

users machine. However this is no trivial task and requires a full understanding of how browsers

respond to HTTP cache headers, heres more info on the subject

Within 10 mins his app was performing about 10 50 times faster. All I did was add a few basic

indexes.

1. Database Indexes + Query Optimisation

This isnt strictly about scaling, but its such a good performance tip: Learn how to do good DB Indexes, they

are really simple and without them youre hemorrhaging your DBs potential performance away. heres a

quick tutorial.

I was having a geek cafe session with my good friend Craig Mod one afternoon and he asked me to look at

his application as it was a bit slow. Within 10 mins his app was performing about 10 50 times faster. All I

did was add a few basic indexes.

As mentioned above, dont forget to turn on the DB query cache.

2. Use a separate database reader and writer

There are a number of reason why at some point youll need a DB master and slave(s) (load balancing,

redundancy, zero downtime backups), you can prepare for this now by having two DB objects e.g $db_reader

and $db_writer

$db_r eader = new db_obj ect ( SLAVE_DSN) ; $db_wr i t er = new db_obj ect ( MASTER_DSN) ;

/ / r eads go t o t he sl ave ( or master) $db_r eader- >query( " sel ect * f r om user where i d = 1" ) ;

/ / wr i t es onl y go t o t he mast er$db_wr i t er- >quer y( "update user set st atus = ' kool kat ' where

i d = 1" ) ;

With a simple change to your DB config this allows you to instantly use a master/slave(s) setup to spread the

load on your database.

3. Account For DB Reader Delays

Allow for the DB reader to be slightly behind the master replicated slaves are likely to periodically lag

behind the master even if just for a second or two. If you are using the tip above and sending reads to a slavethen this could cause problems in your application. For example say a user is logged into a control panel

making changes, if the DB reader is behind the DB writer, then trying to fetch the new changes from the

database will potentially show the old values if the DB reader is behind.

4. Separate Server For Media/Static Files

Ive mentioned this already above, but its worth mentioning again. Set up your site to host all images, js and

css on a domain different from your main website. Id recommend you have some sort of central

configuration so the static server url is automatically included in all image urls e.g.


1 1/24/2012 1


6/9

/ / hand coded ( not r ecommended)

/ / s i mpl e var i abl e


7/9

7. Efficient Backups

Large backups can really slow down or even stop a server (particularly large DB backups), but chances are

you could significantly reduce this load by

Not backing up temp/cache files

Using git/svn etc. and backing up the repository not the web application docroot

Database dumps/snapshots using a slave, so write locks will not affect your DB server

For your data storage use a filesystem/system that support snapshots (e.g. ZFS)

8a. Get into the Cloud

Using virtual servers/cloud computing will give you a certain amount of scalability for free. Most virtual

server providers make it very easy to up the power on your machines, whilst this may not be the most elegant

solution, it saves a massive amount of work compared to the task of migrating dedicated servers.

However thats not the only scalability benefit. You get many of the suggestions Ive made here for free with

Cloud/Virtual computing, e.g.

Easy to clone machines (for setting up multiple identical servers)

On demand computing/per hour billing is great for batch processing

Filesystem snapshots

Robust Storage Solutions (e.g. Amazon S3)

8b. Services Above The Clouds

And last but not least I should mention there are now a number of higher level services, RightScale.com,


1 1/24/2012 1


8/9

Scalr.net, Google App Engine to name a few that offer automatic scalability. If you are able to work within

their constraints (for example App Engine only supports Python + Java) then they can be a very attractive

offering. Google App Engine:

Automatic scaling is built in with App Engine, all you have to do is write your application code

and well do the rest.

As technology advances, a lot of scalability issues become easier to solve or disappear we have cloud

computing, easy to use CDNs and services like Google App Engine. However until we have the Holodeck,

Im pretty confident most of the principles Ive raised today will still be important in your design

considerations.

oh and hopefully your server has stopped melting now.

Heres a few books that have helped me:


1 1/24/2012 1


9/9

Check out a real world example, wikimedia:

http://meta.wikimedia.org/wiki/Wikimedia_servers

highscalability.com has some good resources:

http://highscalability.com/blog/category/blog

Fromwebmastering

5 Comments

Tweets

mrkirkland (mrkirkland) says:

May 13, 2010 at 1:24 am

my new article on scaling websites/web apps http://bit.ly/bRLT0Y

1.

craigmod (Craig Mod) says:

May 13, 2010 at 1:45 pm

Goldmine of website sever scaling tricks by @mrkirklandhttp://bit.ly/bRLT0Y

2.

damiengiard (Giard Damien) says:

May 13, 2010 at 1:48 pm

RT @craigmod: Goldmine of website sever scaling tricks by @mrkirklandhttp://bit.ly/bRLT0Y

3.

DavidAndGoliath (David McKendrick) says:

May 13, 2010 at 1:49 pm


4.

joedevon (Joe Devon) says:

May 13, 2010 at 1:49 pm


5.

Leave a Reply

Name: (required):

Email: (required):

Website:


Documents

Web App for Scalability