Node.js的VS .NET性能 [英] Node.js vs .Net performance

问题描述

我已经读了很多关于Node.js的速度快，并能容纳大量的负载。有没有人有任何这现实世界的证据VS其他框架，特别是净？最让我读过的文章是传闻还是没有攀比.NET。

I've read a lot about Node.js being fast and able to accommodate large amounts of load. Does anyone have any real world evidence of this vs other frameworks, particularly .Net? Most of the articles i've read are anecdotal or don't have comparisons to .Net.

感谢

推荐答案

作为快并处理大量的 LOAD 是两回事。服务器这是真正的快速在服务每秒一个请求可能，如果你把它每秒500个请求完全呱呱叫（在 LOAD ）。

Being FAST and handling lots of LOAD are two different things. A server that's really FAST at serving one request per second might totally croak if you send it 500 requests per second (under LOAD).

您还必须考虑静态的（和缓存）与动态页面。如果你担心静态页面，则IIS很可能会击败节点，因为IIS使用内核模式缓存，这意味着请求请求一个静态页面，甚至没有打算离开的内核。

You also have to consider static (and cached) vs dynamic pages. If you're worried about static pages, then IIS is probably going to beat node because IIS uses kernel-mode caching, which means requests that requests for a static page are not even going to get out of the kernel.

我猜你正在寻找ASP.NET和节点之间的比较。在这场战斗中，一切都被编译后/间preTED你可能会是pretty的接近的性能。也许.NET是一个小的更快或者节点是一个小的更快，但它可能是足够接近，你不关心。我敢打赌.NET的，但我不肯定知道做什么。

I'm guessing that you're looking for a comparison between ASP.NET and node. In this battle, after everything's been compiled/interpreted you're probably going to be pretty close in performance. Maybe .NET's a little FASTER or maybe node's a little FASTER, but it's probably close enough that you don't care. I'd bet on .NET, but I don't know for sure.

这点确实是引人注目的地方是用于处理 LOAD 。这是在技术确实不同。 ASP.NET致力于每个请求的线程从它的线程池，一旦ASP.NET已用尽可用线程请求开始排队。如果你喜欢提供服务的例子由@shankar的Hello World应用程序，那么这可能那么重要，因为线程不会阻塞，你将能够在运行之前处理的请求很多出线程。当你开始做的阻塞线程（呼叫到一个数据库，使一个HTTP请求到服务，从磁盘中读取一个文件）的I / O请求与ASP.NET模型的问题就来了。这些保护请求意味着，从线程池中的宝贵线程无所事事。越堵你，少的 LOAD 您的ASP.NET应用程序将是能够服务。

The place that node is really compelling is for handling LOAD. This is where the technologies really differ. ASP.NET dedicates a thread per request from its thread pool, and once ASP.NET has exhausted available threads requests begin to queue. If you're serving "Hello World" apps like the example by @shankar, then this might not matter that much because the threads aren't going to block and you're going to be able to handle a lot of requests before you run out of threads. The problem with the ASP.NET model comes when you start making I/O requests that block the thread (call to a DB, make a http request to a service, read a file from disk). These blocking requests mean that your valuable thread from the thread pool is doing nothing. The more blocking you have, the less LOAD your ASP.NET app is going to be able to serve.

要prevent这种阻塞，使用I / O完成端口，不需要拿着一个线程，而你的回应等。 ASP.NET支持这一点，但遗憾的是很多的共同框架/在.NET库不。例如，ADO.NET支持I / O完成端口，但实体框架不会使用它们。所以，你可以建立一个ASP.NET应用程序，是纯粹的异步和处理大量的负荷，但很多人并不知道，因为它不是为构建一个是同步的那么容易，你可能无法使用一些自己喜欢的部分框架（如LINQ到实体），如果你做的。

To prevent this blocking, you use I/O completion ports which don't require holding a thread while you wait for a response. ASP.NET supports this, but unfortunately many of the common frameworks/libraries in .NET DON'T. For example, ADO.NET supports I/O completion ports, but the Entity Framework doesn't use them. So you can build an ASP.NET app that's purely asynchronous and handles lots of load, but most people don't because it wasn't as easy as building one that's synchronous, and you might not be able to use some of your favorite parts of the framework (like linq to entities) if you do.

问题是，ASP.NET（和.NET Framework）创建成不自以为是有关异步I / O。 NET不关心，如果你写的同步或异步code，所以它是由开发者做出这个决定。这部分是因为线程和编程异步操作被认为是硬，和.NET希望让每个人都高兴（菜鸟和专家）。因为.NET结束了3-4个不同的模式做异步它得到更加困难。 .NET 4.5正试图回去和改造的.NET框架周围有一个自以为是的模型异步IO，但它可能是一段时间，直到你关心实际的框架支持。

The problem is that ASP.NET (and the .NET Framework) were created to be un-opinionated about asynchronous I/O. .NET doesn't care if you write synchronous or asynchronous code, so it's up to the developer to make this decision. Part of this is because threading and programming with asynchronous operations was thought to be "hard", and .NET wanted to make everyone happy (noobs and experts). It got even harder because .NET ended up with 3-4 different patterns for doing async. .NET 4.5 is trying to go back and retrofit the .NET framework to have an opinionated model around async IO, but it may be a while until the frameworks you care about actually support it.

在另一方面节点的设计，做出了自以为是的选择，所有的I / O应该是异步。因为这个决定的，节点设计者也能够使将只执行code表示已排队的决定，即节点的每个实例将是单线程以最小化线程切换，而且一个线程。这可能是一个新的请求，它可能是从数据库请求回调，它可能是从你犯了一个HTTP REST请求回调。节点试图通过消除线程上下文切换，以最大限度地提高CPU的效率。由于节点做出这个自以为是的选择，所有的I / O是异步的，这也意味着所有它的框架/插件支持这一选择。它更容易编写在节点100％异步应用程序（因为节点迫使你编写的应用程序异步）。

The designers of node on the other hand, made an opinionated choice that ALL I/O should be async. Because of this decision, node designers were also able to make the decision that each instance of node would be single threaded to minimize thread switching, and that one thread would just execute code that had been queued. That might be a new request, it might be the callback from a DB request, it might be the callback from a http rest request you made. Node tries to maximize CPU efficiency by eliminating thread context switches. Because node made this opinionated choice that ALL I/O is asynchronous, that also means that all it's frameworks/add-ons support this choice. It's easier to write apps that are 100% async in node (because node forces you to write apps that are async).

此外，我没有任何确凿的数据来证明这种或那种方式，但我认为节点将赢得典型的Web应用程序的负载的竞争。高度优化的（100％异步）.NET应用程序可能会给相当于Node.js的应用程序运行于它的钱，但如果你把一个普通的所有.NET和所有的节点应用服务在那里，平均节点上可能处理更多LOAD。

Again, I don't have any hard numbers to prove one way or another, but I think node would win the LOAD competition for the typical web app. A highly optimized (100% async) .NET app might give the equivalent node.js app a run for it's money, but if you took an average of all the .NET and all the node apps out there, on average node probably handles more LOAD.

希望有所帮助。

这篇关于Node.js的VS .NET性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！