问node.js本身还是为静态文件提供服务的nginx前端？

EN

我不同意这里的答案。虽然Node会做得很好，但如果配置正确，nginx肯定会更快。nginx是用C语言高效实现的，遵循类似的模式(只在需要的时候才返回连接)，占用的内存很小。此外，它支持sendfile系统调用来服务这些文件，这是您在服务文件时尽可能快的速度，因为它是操作系统内核本身在做这项工作。

到目前为止，nginx已经成为前端服务器的事实标准。您可以利用它在服务静态文件、gzip、SSL甚至稍后的负载平衡方面的性能。

附注:这假设文件实际上是“静态的”，就像请求时磁盘上的静态文件一样。

我对@gremo的图表有不同的解释。在我看来，在相同的请求数量(9-10k之间)下，它同时具有node和nginx规模。当然，nginx的响应延迟降低了20ms，但我认为用户不一定会察觉到这种差异(如果你的应用构建得很好)。给定固定数量的机器，在将节点机器转换为nginx之前，考虑到大多数负载将首先发生在节点机器上，将需要相当多的负载。与此对应的是，如果您已经将一台机器专用于nginx进行负载均衡。如果是这样的话，你也可以让它为你的静态内容提供服务。

这是一个难以回答的问题。如果您编写了一个真正轻量级的节点服务器来只服务静态文件，那么它的性能很可能会比nginx更好，但它并不是那么简单。(Here's a "benchmark"比较nodejs文件服务器和lighttpd -在提供静态文件时，其性能与ngingx相似)。

在服务静态文件方面的性能通常归结为不仅仅是web服务器在做这项工作。如果您想要尽可能高的性能，您将使用CDN为您的文件提供服务，以减少最终用户的延迟，并从边缘缓存中受益。

如果您不担心这一点，node在大多数情况下都可以很好地提供静态文件。Node采用异步代码，这也是它所依赖的，因为它是单线程的，任何阻塞的i/o都会阻塞整个进程，降低应用程序的性能。你很可能是以一种非阻塞的方式编写代码，但是如果你在同步地做任何事情，你可能会导致阻塞，这将降低其他客户端获得静态文件服务的速度。简单的解决方案是不编写阻塞代码，但有时这是不可能的，或者您不能总是强制执行它。