Hi, This is wrong
IIS might have a thread pool but has also had the ability to do non-blocking IO for years The default behaviour of ASP.NET and associated frameworks and the developers using these tools has been to use all the synchronous functionalities available and ignore this - but it is wholly possible to write software on top of IIS for high scale networking (and in fact most of frameworks support this to a large extent) IMO the biggest reasons to use Node over the .NET stack are: - Community (both the people and the packages being churned out) - The overwhelming philosophy of "small things to do do small things right" - NPM (vs NuGet, there is no competition) - A *default* towards writing non-blocking code - Feedback cycles (Nearly all enterprise .NET systems I've ever touched take minutes to build, no thanks) Note I carefully didn't say 'over the ASP.NET MVC stack' - comparing a framework to build network processes against an MVC framework isn't exactly fair - a more rational comparison would be perhaps comparing Express/Restify/Railway with ASP.NET MVC or Socket.IO with SignalR Nor is making the whole 'single threaded async blah makes scaling so easy' any sort of principal argument - if you want to actually scale, you'll have to utilize multiple processes (perhaps even across multiple machines) which means you'll need to synchronize *some *state (or work to avoid it) - neither being easy. Yes it is nice to be able to keep local state and know you haven't got to fight thread safety to do this - but in most situations this is the wrong solution anyway so it isn't that big a win. The number of issues *added* by going down this route probably outweigh the benefits in a lot of cases for most typical enterprise software paths (cost of dealing with async code, dealing with all those little libraries maintained by a thousand different people, etc). Most enterprise developers are monkeys and this is beyond us, we need to be spoon fed and coddled by our frameworks and anything that involves education is scary from a training-cost standpoint On Tuesday, July 3, 2012 8:52:12 PM UTC+2, Dan Milon wrote: > > About performance, from my POV the differences are the concurrency > models each platform uses. > > From one side, IIS has a thread pool, one thread per connection and > blocking IO. > At the other hand, node has one thread, and non blocking IO. > > First approach problem is that memory consumption is increased linearly > with each concurrent request because each thread has its own stack. (try > spinning 10k threads) > > Also the more the requests, the more the threads running, thus more time > is spent on context switching between these threads instead of doing > something valuable. > > The obvious solution would be async & non blocking IO, but it is not so > straight forward to implement it, and any solution wouldnt be cross > platform, but we are lucky all this complexity is abstracted by > libev/libuv. Javascript made a perfect fit for a higher level language > due to language-level anonymous functions & closures which allow you to > write non blocking code easier. > > Of course there are very many problems introduced with async & > javascript, eg callback nightmare and you should be aware you will face > this sooner or later. > > But it is not all about performance. For me, writing nodejs code feels > exciting and very pleasant! The community involved is very active, eager > to help you, and all of this construct a very balanced ecosystem. > > Correct me if im wrong but I believe ASP.NET's community involves old > guys that try out something only if it has the word "enterprise" on the > description. > > Whenever i argue with a friend about performance, threads, async, sync > and stuff it always ends up with drama! Best thing you can do is tell > him you feel nice coding node and have him try it out, think of a > project to do together and have fun etc. Im sure next time he will ask > you to write your next code in node ;) > > Hope I've helped, > Dan Milon. > > > On 07/03/2012 08:56 PM, Justin Collum wrote: > > Had a discussion with a friend about Nodejs the other day. We are both > > C# / MVC / ASP.NET devs, with about 10 years experience. He asked me > > why someone would choose Nodejs over IIS + MVC . My argument was 1) > > performance 2) non-blocking IO. Keep in mind that I don't know a lot > > about node, I've built one small site and that's it. So my argument in > > favor was pretty short. > > > > His response: Well, if I need performance on IIS I can just bump up > > the number of threads in the thread pool. Fair point. > > > > After looking into it a bit, it seems that the big difference between > > IIS + MVC and Node is that each thread can do more in the Node world > > because of the non-blocking IO. This cuts down on context switching > > and makes for better overall performance. Add that to the "one > > language to rule them all: coffeescript" factor and it's a clear win > > to me. > > > > Is that a fair summary of the performance advantages of Nodejs over > > IIS + MVC? Is there more to it? > > > > I'm aware that you can run Nodejs via IIS but my intuition tells me > > that won't be a good fit. > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
