4 ms·
Since when did per minute become a thing? 16K/sec is typical for a node app on fairly avg server.
by qaq 9y ago
Since when did per minute become a thing? 16K/sec is typical for a node app on fairly avg server.
- segmondy 9y agoA million sounds nice.
- GordonS 9y agoYes, but 'per minute' not so much. It really is rather odd to express perf figures like this
- kasey_junk 9y agoIt’s not a thing and it’s fairly trivial to get to that load on a typical go app as well.
- qaq 9y agoI am sure Go can do at the very least 2x-3x vs node for the same workload.
- gazarullz 9y agoSince you are sure, do you have any examples or proof to back that ?
- qaq 9y agoA random result from Google http://blog.digg.com/post/141552444676/making-the-switch-from-nodejs-to-golang 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 :)
- gazarullz 9y agoDon't get me wrong, I don't intend to mock your statement in any way but a statement backed by some data and/or actual examples adds a lot of credibility to it.
- rainbowmverse 9y agoI 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/ 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.
- Thaxll 9y agoSince 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 ...?
- qaq 9y agoIt's obviously application specific in our case data is written to Kafka and a bunch of workers are reading it off and do processing
- KirinDave 9y agoIt 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.
- te_chris 9y agoNew Relic
- KirinDave 9y ago16k 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.
- qaq 9y agoI was not obviously commenting on the content but on a trend of coming up with measurements that make for a catchy title.
- KirinDave 9y ago> 16K/sec is typical for a node app on fairly avg server. This certainly doesn't read like "I'm talking about the title" to me. Also, in other parts of the thread you take performance questions seriously, further diluting the impression your post was about the title or phrasing.
- qaq 9y agoThe title is presenting handling 16K/sec as something special my only original point was that the author is using per minute metrics to make numbers look more impressive. It's very possible that I did a very poor job of making that point :). My comment that I am sure Go more performant than node was beign downvoted so that took things in a diff. direction.