Hacker News Reader

Comment by scandox | Hacker News Reader

> when we started to look at .NET Core in early 2016, it became quite obvious that being able to asynchronously hand off to our queuing service greatly improved throughput. Unfortunately, at the time, Node.js didn’t provide an easy mechanism to do this, while .NET Core had great concurrency capabilities from day one.

This is a mildly maddening article - not because I have any emotional attachment to either platform - but because it never really gets to the heart of the matter. It's like they can tell us, but they'd have to kill us afterwards.

View on HN

I'm with ya. All hype, no details.

A 20X improvement cannot be attributed to .NET core, it must attributed substantially to some implementation/algorithmic issue that they resolved once they got to the .NET core platform. There's a big problem somewhere with node.js if it is 20X slower. If true, then its simply a bug or series of bugs to be fixed in node.js.

Just a basic request/response with barely anything thing in it, shows the .NET core is faster than node.

https://stackoverflow.com/questions/43920942/unexpected-outc...

Obviously this isn't very scientific without a benchmark suite.

It's not 30 times faster. Also, it doesn't matter which one is faster unless there is. Huge speed improvement. Your web server is not the bottleneck.

"Your web server is not the bottleneck." - Highly depends on your setup.

But removing any 3rd party libraries, and external requests. Generally .NET core is faster.

> But removing any 3rd party libraries, and external requests. Generally .NET core is faster.

Is that with reference to "faster than .Net regular" or "faster than node.js"?

You're right either way but I'm not sure that "it's just faster" is all that relevant. The "Just a basic request/response with barely anything thing in it" case removes anything of interest.

For any normal non-trivial, non-demo setup, the web server is fine. I would look at the performance of data stores and other backends. The performance of "asynchronously hand off to our queuing service" is most likely the overriding factor in a 20 or 30x increase.

Some have already optimised the heck out of their data retrieval and writes.

> Some have already optimised the heck out of their data retrieval and writes

Then they have likely not very much to gain from framework speedup either.

The fact that raygun could introduce a "asynchronously hand off to our queuing service" says quite clearly that "already optimised data retrieval and writes" is not the case that we are talking about.

Asynchronously dropping something on to a queue, possibly leaves the queue client implementation as the suspect slowing node down.

But assuming that dropping something on to a queue is incredibly fast. Switching how you serve your http requests can increase performance by some multiples because it would be the largest constant in time taken assuming a very fast queue drop.

Although I agree, if your at that point your probably serving all your requests fine anyway.

Actually 3rd party libraries and application code is where .NET is likely to be faster unless node lib is wrapping a C library - .NET can easily beat JS an order of magnitude simply by having control of memory layouts and high performance/specialized data structures. Meanwhile JS has crap structures (doesn't even have primitive arrays) and everything is it's dynamic object where you pray the JIT eventually figures out a constant structure and tries to optimize.

Yes, but if your going to compare(Badly in this case). You probably want to test it in isolation.

Just to nitpick a bit, JS does have primitive arrays using TypedArray.

This is a good point - it's also why you can still optimize JS on microbenchmarks but for real world code where you'd want to use an array of structs in say C# for eg. there's just no JS equivalent other than write obfuscated stuff around typed arrays.

Honestly, add another machine and the problem is solved. youll be able to afford a team of programmers to rewrite your app in any language of your choosing by the time you feel the slow down.

I'm using .NET core for a production app now. Team of 16. It's working beautifully. The data access is the bottleneck in 99% of what I have ever worked on, not the web framework. That is why Rails is so popular.

> Honestly, add another machine and the problem is solved. youll be able to afford a team of programmers to rewrite your app in any language of your choosing by the time you feel the slow down.

I understand your point, but your statement isn't true in all circumstances. It depends on your business model. Performance begins to matter more when the economics demand it. Say you're working on a game that has a free tier, or a service that offers some things for free and some things paid. Every customer hour costs you a certain amount, and you can expect a certain amount of revenue per customer hour on average. With this kind of a balance, a 20x performance difference can mean a fundamental shift in what kinds of business models can be profitable.

So for something like enterprise software, yeah, add another server. But for something like an MMO or 4Chan performance can be make or break. It's all about cost per user hour vs. revenue per user hour.

The benchmark linked appears to be a 4x speedup that can potentially be attributed to the view engines used. It's really ridiculous to argue for 20x speedups without evidence of the deficit being in the web framework.

So lets take your hypothetical game example... What are your requests doing exactly? Are they returning cached content? If so, the caching policy is more important. If you're running a game, game state is probably changing constantly so you will need to connect to a database. Are you indexing things correctly, sharding, etc? Are you aware that Eve online runs python code?

You can point to any hypothetical scenario where you get a million users on a free tier, but then you will either have to get some funding or start charging for your services. In the case of the chat app Discord, they wrote their server architecture in Elixir, which runs on the Erlang VM called BEAM, which destroys .NET core at scale. Does that mean my team should stop using .NET core? No. I have to consider the knowledge base of the people I currently have as well as familiarity with deployment. The cost of the servers are a lot less important in the real world for 99% of applications any of us will write. I would even argue that it would be better to get to market faster with a product that scales poorly and to scale it as needed. Facebook was and still is written in PHP.

There's very little persistent storage involved with what MMO's and many other kinds of game servers do. Unlike web apps and many business apps, they are definitely not data bound.

I am aware that much of Eve Onlike is written in Python. But they are very premium: $15/mo. Would they be able to support their infrastructure for say $3 from 1 out of every 10 users once every 3 months?

I'm also aware that Facebook was originally written in PHP. Their business model is different, but they are also world leaders in PHP performance and compiling. There's a reason they invested so much in the performance.

>It's not 30 times faster.

That's because the empty request doesn't do much. Start adding real work and the statically typed JIT compiled .NET code shows its real teeth.

It may also be that it's easier to write in performance issues or bugs unintentionally with Node.

I agree with you. A bold claim with very vague explanations makes it a bit hard to believe. I'd love to have more details on how they pulled that off.

this is yet the "more detailed" post. Here is the original story https://customers.microsoft.com/en-US/story/raygun which I objected to https://twitter.com/aliostad/status/849186214045528064

Reply on news.ycombinator.com