3 ms·

This is standard capacity planning which I use to do as an architect in a previous life. It really comes down to your business model and assumptions. You tell

by jtchang 14y ago

This is standard capacity planning which I use to do as an architect in a previous life. It really comes down to your business model and assumptions. You tell me that your model says you will have 1000 users in Month 1, ramping up 100k users / month till month 12? I will then use that to plan everything else. For one project we had a requirement of 500 concurrent users constantly using the system. Disk space was not as big a concern as memory/ram. To support these 500 users we needed about 6 large instances. Yes this is a lot of hardware for a very small # of connections which speaks to how intensive the app was. If you need help be glad to take a look at your specific case.

thspimpolds 14y ago
As jtchang said, yes it comes down to planning. Ask the founders (or if you are one you should know this) what your daily active uniques are. Also ask what language you are getting code in. Java needs more headroom than c++ for instance. Then plan +40% capacity of whatever they tell you. Always use an Aws autoscaling group to shave costs, but price as if you had always on on demand pricing. Don't forget to think about supporting infrastructure. Do you need memcached? If you do how much? Will you run your own or use elasticache? It all comes down to architecting your system on a whiteboard with needed resources (CPU, ram, etc) and then take that and apply it to the the instance type matrix and see where it fits My experience is based on three startups each with 2n or greater redundancy each handling at least 500 req/s into the frontend
chris_dcosta 14y ago
This is a good start but what I'm really looking for is a from scratch plan - that is to say, I actually have no idea where to start. Ok, I know I could pull out of the air a figure for the target nr users that would probably tie up with the projections in the business plan, but that only serves to support the guesswork therein. It's not really based on real world experiences and I don't want to find i'm blowing my cash on AWS and not iteration. For example hosting Pinterest is a vastly different animal than Dropbox. I suppose using that analogy my project is more like a Pinterest with a heavy db transaction side. I may not be looking at Pinterest growth curve (here's hoping of course) but there has to be a starting point.

by jtchang 14y ago

thspimpolds 14y ago

As jtchang said, yes it comes down to planning. Ask the founders (or if you are one you should know this) what your daily active uniques are. Also ask what language you are getting code in. Java needs more headroom than c++ for instance. Then plan +40% capacity of whatever they tell you. Always use an Aws autoscaling group to shave costs, but price as if you had always on on demand pricing. Don't forget to think about supporting infrastructure. Do you need memcached? If you do how much? Will you run your own or use elasticache? It all comes down to architecting your system on a whiteboard with needed resources (CPU, ram, etc) and then take that and apply it to the the instance type matrix and see where it fits My experience is based on three startups each with 2n or greater redundancy each handling at least 500 req/s into the frontend

chris_dcosta 14y ago

This is a good start but what I'm really looking for is a from scratch plan - that is to say, I actually have no idea where to start. Ok, I know I could pull out of the air a figure for the target nr users that would probably tie up with the projections in the business plan, but that only serves to support the guesswork therein. It's not really based on real world experiences and I don't want to find i'm blowing my cash on AWS and not iteration. For example hosting Pinterest is a vastly different animal than Dropbox. I suppose using that analogy my project is more like a Pinterest with a heavy db transaction side. I may not be looking at Pinterest growth curve (here's hoping of course) but there has to be a starting point.