Adrián Ribao - Blog

As the number of users of your web grow up, the resources of the server decrease quickly. What's the next step?
As we are about to see, if we have this situation planned, we can add resources to the server and solve the bottlenecks.

We must have in mind the shared nothing architecture. This means that none of the servers needed for the web application should share the hardware resources. Database and web server should run in different machines, both of them perform an intensive job under heavy loads, and they enjoy eating all the RAM the server can provide, for this reason is a good idea to have them in at least two servers, with all the RAM we can pay in each server. Get enough RAM to get fit your entire database into memory.

Having the media (photos, videos...) served by a light web server is a good idea also. lighthttpd and Tux, perform very well at this tasks (among many others). Usually is not a good idea to have a single server to generate dynamic content and to serve static content, specially if the web is serving thousands of small files, like avatars, because you'll probably find disk IO problems and bottlenecks.

So far we have three servers, one for the dynamic content of the web, other for the DB and the last one for serving static files. With this architecture we can check the status of all of them separately and improve only the things that are necessary. If the DB decreases the performance we'll buy more RAM and tune it, if this is not enough we'll buy another DB server, and configure a pool. The same with the web server, where we can add a load balancer improving both performance and security.

When you add a DB server, some further steps must be taken, of course, both servers must have the same data as the queries should return always the same result from both of them. Take a look at pgpool II it can perform very well and have some interesting features such as replication, load balance, parallel queries and connection pooling.

With this scheme the web application should talk to pgpool and pgpool to the different DB servers optimizing everything.
When the web server is stressed, just add a load balancer and let it distribute the request between the web servers. There are many load balancers available under an open source license.

Web scalability is nice, and even fun, but as the web grow up, not only hardware is important, one of the most important things is a good cache system. You can have from one to several cache servers helping the web and DB servers to reduce their loads. Take a look at: memcache, is a great cache server with very high performance.

With a good cache system and optimized servers, you can serve more than 10 million hits per day with only 3 servers, one for web dynamic content, other for static content and the last one for the DB server this means about 115 request per second.

It's important to take into account from the fists stages of development. Spending some time to optimize the number of request made to the server it's a good idea. For instance, if the website has many images, javascript and CSS files, the browser will make a request for each one and those request are relatively slow. What I mean is that is better to download a single image of 100Kb rather than four images of 25Kb.

You can find more information and case studies in: http://highscalability.com/