[deleted]
Handling 1M Requests per Minute with Go (2015)
11–20 of 39 posts
Re: Handling 1M Requests per Minute with Go (2015)
#12Seems like they just had a misunderstanding of how range worked. And now they have complicated code.
What was the misunderstanding? I'm a Go noob and curious of what they did incorrectly.
Edit: I read the comments at the end of the article and my question was answered.
Re: Handling 1M Requests per Minute with Go (2015)
#13Earlier quoted context omitted.
Since you are sure, do you have any examples or proof to back that ?
A random result from Google http://blog.digg.com/post/141552444676/making-the-switch-fro... . My day job is writing large scale node services that service over million concur. clients doing fairly intensive data acquisition/processing so I am not hating on Node :)
I think Golang benefits from two related things:
1: There's basically one way to do anything, even if you pull in a library that collects those one ways to do another thing.
2: Those one ways are each developed by some of the most skilled engineers in the world and documented by someone with amazing clarity. (https://golang.org/pkg/)
I have always had a lot of trouble trying to learn to program (used to struggle more with focus and memory), but Golang is just easy. I can look at an API I wrote as a learning project after 6 months of not writing any code and understand it perfectly.
Node was not so bad when things worked, but I hit the same brick wall I did with [insert language] when something didn't go like the guide said it should.
Re: Handling 1M Requests per Minute with Go (2015)
#14Why didn't he keep the first single-channel solution and just listen on the channel from multiple go routines? I don't see the advantage that a tiered approach gets you over that.
Yeah, I fail to understand the purpose of the dispatcher thingy aswell. This also can run out of memory as he keeps spawning routines indefinately with each request in the dispatcher.
Re: Handling 1M Requests per Minute with Go (2015)
#15Since when did per minute become a thing? 16K/sec is typical for a node app on fairly avg server.
New Relic
Re: Handling 1M Requests per Minute with Go (2015)
#16Re: Handling 1M Requests per Minute with Go (2015)
#17I appreciate thoughtful posts like this. Instead of the typical "Go is just better" style of article with specious data, this one talks about pitfalls around Go. All developers need to realize that there are tradeoffs with any implementation and this blog does a great job illustrating that.
Re: Handling 1M Requests per Minute with Go (2015)
#18Since when did per minute become a thing? 16K/sec is typical for a node app on fairly avg server.
16k r/s is not trivial to get for a non-hello-world app on NodeJS even on a big server, but if you read the article you'd see it's actually about a quarter of that.
... Yeah basically it is an article about using concurrency.
Re: Handling 1M Requests per Minute with Go (2015)
#19Earlier quoted context omitted.
It’s not a thing and it’s fairly trivial to get to that load on a typical go app as well.
I am sure Go can do at the very least 2x-3x vs node for the same workload.
It depends on the workload.
CPU bound? For sure.
Fake CPU bound (as this one is, spending tons of time in go's concurrency machinery), clearly not.
I/O bound? I would have said no before Spectre and Meltdown ruined all our intuitions about performance. It's just a mess right now.
Re: Handling 1M Requests per Minute with Go (2015)
#20Earlier quoted context omitted.
Since you are sure, do you have any examples or proof to back that ?
A random result from Google http://blog.digg.com/post/141552444676/making-the-switch-fro... . My day job is writing large scale node services that service over million concur. clients doing fairly intensive data acquisition/processing so I am not hating on Node :)
Since Node is single threaded how do you make that scale on multi core without something that spawn multiple Node app and thus using 2x 3x 4x the memory ...?