4 ms·

Why do you need a fleet of VMs? Go can serve about 500M users per month on Xeon E3 v2 CPUs. Why, except for HA do you need more? Do you know how much 5000 (a

Why do you need a fleet of VMs? Go can serve about 500M users per month on Xeon E3 v2 CPUs. Why, except for HA do you need more? Do you know how much 5000 (and more in reality) concurrent requests are, and I'm just talking HTTP1.1 requests? And with HTTP/2 and 48 cores 96 threads and even 24c/48t commodity hardware that's multiples of 5k concurrent rps. Of course if you insist on using low performance php, node, ruby, elixir that's your own fault. "Scale" my ass. Just another FUD buzzword to sell expensive proprietary services.

rented_mule 2y ago
I'm not who you're responding to, but... > Go can serve about 500M users per month on Xeon E3 v2 CPUs. > Why, except for HA do you need more? Because not everything is a simple CRUD website. The last place I worked had a website that appeared to only be moderately more complex than such a site, and had well under 500M users per month. But parts of the application involved complicated processing of many dozens of TBs per day of newly collected data to optimize the content being served (some stream processing, some batch). We had multiple clusters of 1,000+ machines coming and going for an hour or two at a time (often overlapping).
YZF 2y ago
The problem isn't the 5000 request/s on your Go code. What do these requests do? Is there a database? Is it replicated? How large does it need to be? How complex are the transactions/queries? What happens when your one server goes down? What happens when the Data Center hosting your server(s) goes down? Do you have a large dev team? How do they develop? How do they test? How large is your application? What happens when your company builds new applications? How do you do updates/upgrades of your software and the dependencies? Do you have a staging environment? Most of my experience is with high performance software. C++/C and yeah lots of Go. My observations aren't related to performance. There's more to scale and providing a reliable service than performance. I am totally onboard with the idea that people often go horizontally when they don't need to performance-wise because they choose slow tools. This is not what I'm talking about here. That said, there's probably a class of problems that are fine with just one VM. So if that's what you have, go for it (which is what I said in my original comment).

rented_mule 2y ago

I'm not who you're responding to, but... > Go can serve about 500M users per month on Xeon E3 v2 CPUs. > Why, except for HA do you need more? Because not everything is a simple CRUD website. The last place I worked had a website that appeared to only be moderately more complex than such a site, and had well under 500M users per month. But parts of the application involved complicated processing of many dozens of TBs per day of newly collected data to optimize the content being served (some stream processing, some batch). We had multiple clusters of 1,000+ machines coming and going for an hour or two at a time (often overlapping).

YZF 2y ago

The problem isn't the 5000 request/s on your Go code. What do these requests do? Is there a database? Is it replicated? How large does it need to be? How complex are the transactions/queries? What happens when your one server goes down? What happens when the Data Center hosting your server(s) goes down? Do you have a large dev team? How do they develop? How do they test? How large is your application? What happens when your company builds new applications? How do you do updates/upgrades of your software and the dependencies? Do you have a staging environment? Most of my experience is with high performance software. C++/C and yeah lots of Go. My observations aren't related to performance. There's more to scale and providing a reliable service than performance. I am totally onboard with the idea that people often go horizontally when they don't need to performance-wise because they choose slow tools. This is not what I'm talking about here. That said, there's probably a class of problems that are fine with just one VM. So if that's what you have, go for it (which is what I said in my original comment).