3 ms·

so a poorly written app in tech x performs worse than a better written app in tech y. who would have thought!

BozeWolf 10y ago
Agree! It makes you wonder why they didnt try python 3.5 with async stuff, as most of their stack is based on python. Yes its not multi threaded but if the service was rewritten it might have actually performed better. Otoh: sometimes you need a good excuse to test some other technologies.
- ciokan 10y ago
  Care to explain why python async would have performed better? I don't see a single way in which python async would be a better alternative for the given job. I'm a python guy myself but, when it comes to async stuff, I find nodejs much better and easier to understand/follow through (even with cb madness yes). For the described job, I would have went with Elixir or Go as well yes.
- Can_Not 10y ago
  Doesn't really make me wonder. I haven't really seen anything about python's new async stuff that indicates it's on par with node's (reply here if you found anything, I've been looking for this information!). And if python is caught up with node, it would be at very high risk of performing the same and having another random performance gotcha. Golang is one of the natural choices to replace a nodejs application for performance reasons. It's low-level, faster, uses less memory.
mrweasel 10y ago
That's not the message of the article. The original application wasn't poorly written. In fact it was written by people who know Javascript and refactored multiple times. The new application is written by someone that picked up Go in a few weeks. I don't see it as a criticism Node.js either, it's just that Node wasn't the right tool for the job, in this case. If you pick the correct tools and know the limitations of your tools, then it becomes less important how proficient you are with those tools (not irrelevant of cause).
- chadscira 10y ago
  I would like to know more about the implementation. I have had node do 12000 requests a minute with no problem (on a single core). In this case they had 4 two core boxes, so they needed each one to at least perform 42 requests a second under max load. I want to know more :)
  - justsumbody 10y ago
    That's not really that fast... and probably doesn't hold up anyway under diverse request types. http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/ http://marcio.io/2015/07/handling-1-million-requests-per-min... etc
- supermatt 10y ago
  Its evident from the flamegraph that the architecture is fundamentally different. Why are the stacks so deep in the javascript example? Why aren't they using a similar worker pool in the node implementation? Are they just throwing everything onto the event queue and treating that as a naive worker pool? If you know the limitations of your tools then you can work around them. This was clearly not done in this case.

Agree! It makes you wonder why they didnt try python 3.5 with async stuff, as most of their stack is based on python. Yes its not multi threaded but if the service was rewritten it might have actually performed better. Otoh: sometimes you need a good excuse to test some other technologies.

ciokan 10y ago
Care to explain why python async would have performed better? I don't see a single way in which python async would be a better alternative for the given job. I'm a python guy myself but, when it comes to async stuff, I find nodejs much better and easier to understand/follow through (even with cb madness yes). For the described job, I would have went with Elixir or Go as well yes.
Can_Not 10y ago
Doesn't really make me wonder. I haven't really seen anything about python's new async stuff that indicates it's on par with node's (reply here if you found anything, I've been looking for this information!). And if python is caught up with node, it would be at very high risk of performing the same and having another random performance gotcha. Golang is one of the natural choices to replace a nodejs application for performance reasons. It's low-level, faster, uses less memory.

mrweasel 10y ago

That's not the message of the article. The original application wasn't poorly written. In fact it was written by people who know Javascript and refactored multiple times. The new application is written by someone that picked up Go in a few weeks. I don't see it as a criticism Node.js either, it's just that Node wasn't the right tool for the job, in this case. If you pick the correct tools and know the limitations of your tools, then it becomes less important how proficient you are with those tools (not irrelevant of cause).

chadscira 10y ago
I would like to know more about the implementation. I have had node do 12000 requests a minute with no problem (on a single core). In this case they had 4 two core boxes, so they needed each one to at least perform 42 requests a second under max load. I want to know more :)
- justsumbody 10y ago
  That's not really that fast... and probably doesn't hold up anyway under diverse request types. http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/ http://marcio.io/2015/07/handling-1-million-requests-per-min... etc
supermatt 10y ago
Its evident from the flamegraph that the architecture is fundamentally different. Why are the stacks so deep in the javascript example? Why aren't they using a similar worker pool in the node implementation? Are they just throwing everything onto the event queue and treating that as a naive worker pool? If you know the limitations of your tools then you can work around them. This was clearly not done in this case.