15

After reading a lot of stuff about nodejs, I still ask my self :

What are the benefits over asp.net HttpAsync requests ?

The only limitation ( as I see) is the concurrent number of requests which IIS limits.

I tried to paint how I currently understand it :

enter image description here

any help ?

  • is there anything that asynchronous operations on .net/ado.net can't do that nodejs can ?
Royi Namir
  • 144,742
  • 138
  • 468
  • 792

2 Answers2

13

IIS limits the number of concurrent requests to a high number by default. The limit can be raised arbitrarily though.

There are two main benefits attributed to node.js:

  1. Scalability (not performance! there is a difference) due to async IO
  2. Sharing Javascript with the client

ASP.NET does not support number 2 so that is an advantage.

Async IO and non-blocking code is fully supported by ASP.NET. Plus, you get the performance advantage of a JITed statically typed language. For that reason ASP.NET generally has superior performance to node.js for non-toy applications (printing "hello world" is not a real benchmark workload! neither is sleeping for 10 seconds).

node.js benefits from the extremely slim code-path it has. For that reason very minimal applications like "echo" or "hello world" are probably faster. This does not hold for apps which actually perform work.

So if you want to know which is "better" you need to consider a particular scenario. Benchmark with a realistic workload (no, calculating a factorial number is not realistic. C# is just going to win by a large amount. Means nothing). Also factor in maturity of the platform, libraries, documentation, support, developer productivity, ....

usr
  • 168,620
  • 35
  • 240
  • 369
  • I think Also that nodejs support tcp while asp.net doesnt ( http requst) – Royi Namir Sep 11 '12 at 20:52
  • That might be the case. IIS supports TCP though. WCF uses it to run binary service endpoints. – usr Sep 11 '12 at 20:56
  • when I'm creating a http server using node.js - each request to the server is being handled by a regular thread and not from the thread pool...right ? – Royi Namir Sep 29 '12 at 19:37
  • 1
    @Venemo JIT's are different. The V8 JIT, while of high quality, realistically cannot be on-par with the CLR JIT because it has to support dynamic code features which the CLR does not. And indeed, the performance differential between the two for reasonably optimized and idiomatic code is very high (not percent but integer factors). This is not a subjective judgement of mine or a conjecture. It is objectively the case. – usr Mar 14 '13 at 22:31
  • @usr Unless you have some benchmarks or reproducible tests, I would tend to disagree with your assessment. – Venemo Mar 19 '13 at 20:22
  • 1
    @Venemo The best I can offer is to look at popular language shootouts and to look at the internals of V8. The former proves my point for the present, the latter will make you understand why the present state will not change until performance parity is reached. It cannot due to the inherent dynamism which leads to an unbridgable impedance mismatch between what JavaScript needs and what an x86 CPU needs.; Also, it goes the other way around: Produce a benchmark that disproves me. – usr Mar 19 '13 at 20:31
  • @usr Once I have some free time for that, I probably will benchmark it just for fun, until then, we won't know for certain. :) – Venemo Mar 19 '13 at 21:18
  • @usr, "Produce a benchmark that disproves me.", +1 for pure logic. – cwharris Aug 08 '13 at 22:41
5

The main difference between node.js and ASP.NET is the library eco system. Most node.js libraries provide an asynchronous way. ASP.NET methods don't, only a few of them do. And if there is something synchronous along the way, the point of being asynchronous is lost.

That's the problem most platforms have compared to node.js.

Otherwise, just using this AsyncHttp method, there is no difference between ASP.NET and node.js.

Florian Margaine
  • 58,730
  • 15
  • 91
  • 116