Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What drove the choice to the larger instance types instead of more of the small ones? Not questioning your judgment I'm just curious.


We moved from Python to Go. With Python behind uwsgi->nginx, we'd try to tune the number of uwsgi processes to cores, and it was easy to scale up based on process=number of concurrent requests handled. With Go, every request is handled concurrently, being much more efficient with cores and RAM. I found that my requests/core were being artificially limited by RAM in an autoscaling group (we had scaling triggered at about avg 80% CPU) so I let some more RAM play.

Now, instead of 15-20 c3.medium servers at peak, we run three c3.xlarge instances at peak. I can be sure that the larger server will handle more concurrent requests than process-restricted uwsgi, and thus be able to better allocate the resources given to us by larger instances.


Thanks for the reply. Makes sense. Lots of people don't bother to look at their instance types per application or they run so much in a single instance type that it's both io and memory and network bound in a single instance depending on what the users are doing.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: