4 ms·

Well, a larger chunk of that is the database. A db.r3.4xlarge runs about $1600 by itself. We have several hundred gig of data, and indexes alone keep us in that

Well, a larger chunk of that is the database. A db.r3.4xlarge runs about $1600 by itself. We have several hundred gig of data, and indexes alone keep us in that instance size for RAM allotment. Aside from that, we run 2-3 c3.xlarge API servers, two c3.medium webserver (hosts Facebook versions of our games) and two more c3.medium servers are joining in for a new launch next month. We have one large (size escapes me) ElastiCache instance. 3 ELBs sit in front of those servers, all in a VPC. Finally, we have 11 or so S3 buckets that back Cloudfront distributions for static content for websites and whatnot. We also pay for several TB of traffic per month, and enterprise support. Finally, we're paying for not having to fix any hardware ever, 5 minute incremental DB backups, a VPC I can define in a JSON doc, automatic failovers, and so much more, managed by yours truly, a software engineer, not a network/server/devops/etc. engineer. Yeah, there's a premium, but so far it's paid off.

grogenaut 10y ago
What drove the choice to the larger instance types instead of more of the small ones? Not questioning your judgment I'm just curious.
- themartorana 10y ago
  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.
  - grogenaut 10y ago
    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.

grogenaut 10y ago

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

themartorana 10y ago
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.
- grogenaut 10y ago
  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.