Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Raygun increased throughput 20x with .NET Core over Node.js

raygun.com

Post reply on HN
Print view View original

31–40 of 61 posts

Re: How Raygun increased throughput 20x with .NET Core over Node.js

#31

Post by revelation »

endorphone wrote: post #18

This, and the AgeOfAscent piece it links to, both read like PR pieces commissioned by Microsoft. Both are absent of actual information to really determine what exactly they were testing, or what this means to anyone else's problem space. Because, of course, when you get to the fun of benchmarks there's always a faster options. With .NET Core offering them 20,000 requests per second (on a C3.large), that is a terribly…

Duh, yes, of course the logic makes it much slower than copying a L1 cached static response to the client. But then that is not a use case anyone cares very much about.

The AgeOfAscent story is not a PR piece, the writer (Ben Adams) is a very active contributor to the Kestrel server behind .NET Core. If he's writing about improved performance it's probably because he wrote >1/3rd of the patches.

Re: How Raygun increased throughput 20x with .NET Core over Node.js

#33

Post by markrendle »

allannienhuis wrote: post #23
kompuuter wrote: post #19

Earlier quoted context omitted.

> The fact that they were only getting 1k reqs/sec with Node gives me concern. It clearly shows something went wrong there very early on at a very fundamental level. Because the program is performing CPU compute for each request. Node is single threaded. It's a shame that the Node project killed off the multithreaded web workers pull request. It sorely needs that functionality. Pools of node processes are a poor subs…

Care to elaborate on why additional node processes are a poor substitute? They are really easy to reason about, and to manage. What are the downsides? Not trolling, really interested in hearing about pros/cons.

One obvious thing is that multiple processes means no sharing of any kind of state or in-memory cache, so you immediately have to go to an external cache like Redis or whatever, with the additional maintenance and minor performance hit.

Re: How Raygun increased throughput 20x with .NET Core over Node.js

#34

Post by endorphone »

revelation wrote: post #31
endorphone wrote: post #18

This, and the AgeOfAscent piece it links to, both read like PR pieces commissioned by Microsoft. Both are absent of actual information to really determine what exactly they were testing, or what this means to anyone else's problem space. Because, of course, when you get to the fun of benchmarks there's always a faster options. With .NET Core offering them 20,000 requests per second (on a C3.large), that is a terribly…

Duh, yes, of course the logic makes it much slower than copying a L1 cached static response to the client. But then that is not a use case anyone cares very much about. The AgeOfAscent story is not a PR piece, the writer (Ben Adams) is a very active contributor to the Kestrel server behind .NET Core. If he's writing about improved performance it's probably because he wrote >1/3rd of the patches.

Duh, yes, of course

What a weirdly trite response given that you're essentially repeating what I said. And without specifics the linked piece, and its claims about benchmarks, is utterly meaningless.

"Rewrote inefficient code. Now it's faster. Story at 11!"

The AgeOfAscent story is not a PR piece

Humorously it was likely a "copy a L1 cached static response" type benchmark.

Okay, so it wasn't PR, it was self-aggrandizement (which is effectively PR). Got it. Though in this article it was linked as a performance improvement of "switching" to .NET Core, when really it was a story of terribly inefficient .NET Core code becoming better, though again in a nutshell it is meaningless. Cool.

Re: How Raygun increased throughput 20x with .NET Core over Node.js

#35

Post by draw_down »

> From the questions we received around the specifics of our performance improvements, there seems to be two schools of thought:

> 1. Of course it’s faster, Node is slow

> 2. You must be doing Node wrong, it can be fast

Allow me to offer a third :)

When you rewrite something, it had better be faster! You know a lot more about how it works and how it's used than you knew at the outset. There was a recent post, about going back to Ruby after creating the first version in Clojure, that touches on this point.

Re: How Raygun increased throughput 20x with .NET Core over Node.js

#37

Post by markrendle »

Here's what I read: they had a solution written in Node.js; they rewrote the solution in .NET Core; it was 20x faster. It's anecdotal, sure, and Microsoft prompted them to write it, and YMMV, but they did a thing and it had a remarkable result so they've remarked on it. It's not realistic to expect them to take the time to build a representative sample that doesn't expose any of their proprietary business logic; they're running a business and have more important things to do.

Anecdote of my own: I was working on a web bug that had to generate a few v4 UUIDs on every request, and using a version of Node for which the libuuid wrapper wasn't working, so I was using the fastest script-based generator I could find, but it was still too slow. A .NET Core version of the same code handled something like 40x the number of requests on the same hardware.

If nothing else, it demonstrates that using the same solution for all your different problems is A Bad Thing, because there are surely things that .NET Core is not particularly good at either.

Re: How Raygun increased throughput 20x with .NET Core over Node.js

#38

Post by venning »

endorphone wrote: post #18

This, and the AgeOfAscent piece it links to, both read like PR pieces commissioned by Microsoft. Both are absent of actual information to really determine what exactly they were testing, or what this means to anyone else's problem space. Because, of course, when you get to the fun of benchmarks there's always a faster options. With .NET Core offering them 20,000 requests per second (on a C3.large), that is a terribly…

With respect to the TechEmpower benchmarks, if you look at Round 13 [1] they note that ASP.NET got 859 times faster in their benchmarks since Microsoft dedicated effort to improving it.

[1] https://www.techempower.com/blog/2016/11/16/framework-benchm...

Re: How Raygun increased throughput 20x with .NET Core over Node.js

#40

Post by endorphone »

venning wrote: post #38
endorphone wrote: post #18

This, and the AgeOfAscent piece it links to, both read like PR pieces commissioned by Microsoft. Both are absent of actual information to really determine what exactly they were testing, or what this means to anyone else's problem space. Because, of course, when you get to the fun of benchmarks there's always a faster options. With .NET Core offering them 20,000 requests per second (on a C3.large), that is a terribly…

With respect to the TechEmpower benchmarks, if you look at Round 13 [1] they note that ASP.NET got 859 times faster in their benchmarks since Microsoft dedicated effort to improving it. [1] https://www.techempower.com/blog/2016/11/16/framework-benchm...

Indeed (though it's worth noting that they're talking about the performance of ASP.NET Core versus Mono, which was notoriously disastrous performance wise, and that story got somewhat misrepresented). In no way am I saying that the .NET Core is slow.

But if we want to use that benchmark, doing the most trivial useful thing of all -- serializing a simple object to JSON -- and node.js beat core .net. In the recent iteration it beat it by almost 2x (which makes the "node.js is slow we all know that" bit in the linked piece humorous given that it beats aspnetcore in every test but plaintext, which is an irrelevant test anyways given that they put their service behind nginx).

I don't use node.js. I don't advocate it. I personally think most node.js solutions end up being a spaghetti mess. But these sorts of "the details are hidden but look at the magic we wrought!" benchmarks are worse than useless. They're fools gold for people choosing platforms and thinking this sort of advocacy is guidance to learn from.

Post reply on HN