3

Possible Duplicate:
Can you help me with my capacity planning?

My team has created a nice django app and now it is going to be deployed on an EC2 instance. Now there are a few questions that I am looking answer for:

  • How do I decide which instance is good for my app (micro, small, medium, large etc.). In other words how can I tell how much memory/processing power is required by this application.
  • How can I quantify maximum number of concurrent users on my server. This is important for this application, I need to know how many users would be supported by micro/small/medium or large instance.
  • Should I go for everything installed on a single instance or should I have separate instance for database, backups and application.
  • How can I have an estimate of extra resources required with addition of each user (I think this would not be linear)

I know that answer to these questions are very subjective and most of the things depend on application design and architecture. Therefore, I am more interested in getting to know the process involved in making such decisions.

0

1 Answer 1

5

You've pointed out for yourself, at the end of the question, that is not possible to give a direct, objective answer to your question other than "it depends", so I'll try to help based on my (not vast) experience using AWS.

How do I decide which instance is good for my app (micro, small, medium, large etc.). In other words how can I tell how much memory/processing power is required by this application.

By testing, bench-marking, experimenting. There are several articles out there pointing out how EC2 under-performs when compared to "equivalent" hardware specs from other providers (this is a good one). My suggestion would be to set up an environment with your best guess, and monitor, load test, bench-mark your instance(s), playing around with new instances and deciding which one best fits your application requirements. Without further details of your architecture, this is the best answer you might have.

How can I quantify maximum number of concurrent users on my server. This is important for this application, I need to know how many users would be supported by micro/small/medium or large instance.

Again, this heavily depends on your system architecture and on the profile of your transactions. Are they I/O intensive, cpu-bound, memory-bound? The best tip is you should experiment.

Should I go for everything installed on a single instance or should I have separate instance for database, backups and application.

I recommend having separate instances for each tier of your application. A typical setup on AWS would include EC2 instances (behind an Elastic Load Balancer or not) (or Elastic Beanstalk) for your application, another set of EC2 instance(s) or RDS for your database, S3 for persisting files and backups and so on. If you do not expect a huge (or not even a moderate) load, a single, medium instance might perfectly fit your needs. The main rationale for having a separation is that you can scale them independently in the future. This is, IMHO, the best benefit of AWS: flexibility. You can scale your RDS system with a click of your mouse (almost literally). You can also add an Elastic Load Balancer in front of your web tier without much effort, and then add 2 or 3 additional web servers to your ecosystem. So, I would keep things separate, in order to maximize and leverage this flexibility.

How can I have an estimate of extra resources required with addition of each user (I think this would not be linear)

Experimenting, bench-marking, etc. Sorry for being repetitive, but as you start deploying your resources, you will realize that things are really not linear, and that your expectations might not always be true when using AWS. By following some simple tips (like the answer I gave for the previous bullet), it is not guaranteed that your system will easily scale according to your load, but things will likely be less painful whenever you need to scale.

Hope it helps.

Not the answer you're looking for? Browse other questions tagged .