How to gear towards scalability for a start up e-commerce portal?

Question

I want to scale an e-commerce portal based on LAMP. Recently we've seen huge traffic surge.

What would be steps (please mention in order) in scaling it:

1. Should I consider moving onto Amazon EC2 or similar? what could be potential problems in switching servers?

2. Do we need to redesign database? I read, Facebook switched to Cassandra from MySql. What kind of code changes are required if switched to Cassandra? Would Cassandra be better option than MySql?

3. Possibility of Hadoop, not even sure?

4. Any other things, which need to be thought of?

Found this post helpful. This blog has nice articles as well. What I want to know is list of steps I should consider in scaling this app.

Answer 1

First, I would suggest making sure every resource served by your server sets appropriate cache control headers. The goal is to make sure truly dynamic content gets served fresh every time and any stable or static content gets served from somebody else's cache as much as possible. Why deliver a product image to every AOL customer when you can deliver it to the first and let AOL deliver it to all the others?

If you currently run your webserver and dbms on the same box, you can look into moving the dbms onto a dedicated database server.

Once you have done the above, you need to start measuring the specifics. What resource will hit its capacity first?

For example, if the webserver is running at or near capacity while the database server sits mostly idle, it makes no sense to switch databases or to implement replication etc.

If the webserver sits mostly idle while the dbms chugs away constantly, it makes no sense to look into switching to a cluster of load-balanced webservers.

Take care of the simple things first.

If the dbms is the likely bottle-neck, make sure your database has the right indexes so that it gets fast access times during lookup and doesn't waste unnecessary time during updates. Make sure the dbms logs to a different physical medium from the tables themselves. Make sure the application isn't issuing any wasteful queries etc. Make sure you do not run any expensive analytical queries against your transactional database.

If the webserver is the likely bottle-neck, profile it to see where it spends most of its time and reduce the work by changing your application or implementing new caching strategies etc. Make sure you are not doing anything that will prevent you from moving from a single server to multiple servers with a load balancer.

If you have taken care of the above, you will be much better prepared for making the move to multiple webservers or database servers. You will be much better informed for deciding whether to scale your database with replication or to switch to a completely different data model etc.