After the easy stuff: move your database to its own server, add a load balancer in front of additional web servers, implement memcached, start splicing your database to multiple servers, continue to add web servers, serve your static files from a cdn
I'd suggest implementing memcached before adding a second DB server, often this can help in scaling incredible amounts. We had an application which as soon as we implemented memcached(we really should have off the bat) the load was cut over 1/2. Of course this was an extreme example since the server was getting pounded with tons of reads from our DB every second.
Before adding the load balancer make sure you stress test your app to know where the bottleneck is (CPU, memory, disk, network etc). See if you can't double your throughput by some cheap upgrades e.g. if you are CPU bound on a single core, you'll buy yourself some breathing space by upgrading to dual or quad core processors. If you are CPU bound but have loads of free memory consider caching expensive queries in RAM for a few seconds.
I only point this out, as load balancers and additional servers can be expensive.
Split static content serving from dynamic. Can start off on same server but requirements for each are so different it pays to have tuned processes serving each.
Build customized, svelt apache or use nginx.
Get separate DB server, get lots mem for DB server, tune DB to use that memory. Few/None are setup up out of box to use 4-8GB+ well.
Get more mem for http box(es), use memcache/similar to take advantage of that memory.
I usually find my apps are CPU bound rather than memory intensive, so it pays to test this out. Easy way to find out is to run apache bench locally and watch the server performance (Use perfmon on windows, not sure what the linux/unix alternative is). Its a crude performance metric but will point you in the right direction as to what you want to upgrade first, you can validate your findings with a more complex tool like Webload/JMeter/Wcat if you want to make sure.
Comments
After the easy stuff: move your database to its own server, add a load balancer in front of additional web servers, implement memcached, start splicing your database to multiple servers, continue to add web servers, serve your static files from a cdn
I'd suggest implementing memcached before adding a second DB server, often this can help in scaling incredible amounts. We had an application which as soon as we implemented memcached(we really should have off the bat) the load was cut over 1/2. Of course this was an extreme example since the server was getting pounded with tons of reads from our DB every second.
Before adding the load balancer make sure you stress test your app to know where the bottleneck is (CPU, memory, disk, network etc). See if you can't double your throughput by some cheap upgrades e.g. if you are CPU bound on a single core, you'll buy yourself some breathing space by upgrading to dual or quad core processors. If you are CPU bound but have loads of free memory consider caching expensive queries in RAM for a few seconds.
I only point this out, as load balancers and additional servers can be expensive.
What would be the first thing you do? All that adds up...
Depends on your app, but...
Split static content serving from dynamic. Can start off on same server but requirements for each are so different it pays to have tuned processes serving each.
Build customized, svelt apache or use nginx.
Get separate DB server, get lots mem for DB server, tune DB to use that memory. Few/None are setup up out of box to use 4-8GB+ well.
Get more mem for http box(es), use memcache/similar to take advantage of that memory.
first thing to do, IMO: Add more RAM
I usually find my apps are CPU bound rather than memory intensive, so it pays to test this out. Easy way to find out is to run apache bench locally and watch the server performance (Use perfmon on windows, not sure what the linux/unix alternative is). Its a crude performance metric but will point you in the right direction as to what you want to upgrade first, you can validate your findings with a more complex tool like Webload/JMeter/Wcat if you want to make sure.
also
1. caching is your friend
2. you probably need 2 load balancer (instead of 1) for high availability
3. probably need a SAN or shared storage somewhere when you have several web servers
baller