node.js本身或nginx前端服务静态文件?

是否有任何基准或比较更快:将nginx放在节点前面,让它直接提供静态文件,或者只使用节点并使用静态文件?

Nginx的解决scheme似乎更容易pipe理我的任何想法?

我不得不不同意这里的答案。 虽然节点会做的很好,如果configuration正确,nginx肯定会更快。 nginx在C中遵循一种类似的模式(仅在需要时才返回连接)以高效的方式实现,只占用很小的内存空间。 此外,它支持sendfile系统调用,以便为服务文件提供尽可能快的文件服务,因为这是操作系统内核本身。

到目前为止,nginx已经成为前端服务器的事实标准。 您可以使用它来提供静态文件,gzip,SSL,甚至以后的负载平衡。

PS:这个假设文件是​​真正的“静态”,就像请求时在磁盘上rest一样。

我做了一个快速ab -n 10000 -c 100服务一个静态1406字节favicon.ico ,比较nginx,Express.js(静态中间件)和群集Express.js。 希望这可以帮助:

在这里输入图像说明

不幸的是,我不能testing1000甚至10000个并发请求,因为我的机器上的nginx会开始抛出错误。

编辑 :如artvolkbuild议,这里是集群+ static中间件(较慢)的结果:

在这里输入图像说明

无论哪种方式,我会设置Nginxcaching静态文件 …你会看到巨大的差异。 然后,无论你是否从节点服务他们,你基本上获得相同的性能和相同的节点应用程序的卸载。

我个人不喜欢我的Nginx前端在大多数情况下提供静态资产的想法

1)项目现在必须在同一台机器上 – 或者必须分成资源(在nginx机器上)和web应用程序(在多台机器上进行缩放)

2)Nginxconfiguration现在必须维护静态资产的path位置/重新加载时,他们改变。

我对@ gremo的图表有不同的解释。 它看起来像节点和nginx规模在相同的请求数量(9-10k之间)。 确保nginx的响应延迟低20ms,但我不认为用户会觉得这个差别(如果你的应用程序编译的很好)。 考虑到固定数量的机器,在将节点机器转换为nginx之前,需要花费相当多的负载,因为节点首先将负载大部分负载。 与之相对的是,如果您已经将一台机器专用于nginx进行负载均衡。 如果是这样的话,那么你也可以让它为你的静态内容提供服务。

这是一个棘手的问题要回答。 如果你编写了一个真正的轻量级节点服务器来提供静态文件,那么它最有可能比Nginx更好,但并不是那么简单。 ( 下面是比较nodejs文件服务器和lighttpd 的“基准testing” – 在服务静态文件时,它与ngingx的性能类似)。

服务静态文件的性能往往不仅仅是Web服务器的工作。 如果您希望获得最高的性能,那么您将使用CDN来为您的文件提供服务,以减less最终用户的延迟,并从边缘caching中受益。

如果你不担心,大多数情况下节点可以静态的文件。 节点适用于asynchronous代码,由于它是单线程的,所以它也依赖于asynchronous代码,任何阻塞I / O都可能阻塞整个进程,并降低应用程序的性能。 你很可能以非阻塞的方式编写你的代码,但是如果你正在同步做任何事情,你可能会造成阻塞,这会降低其他客户端获得静态文件的速度。 简单的解决scheme是不写封锁的代码,但有时候这是不可能的,或者你不能总是执行它。

我确信纯粹的node.js在很多方面都可以胜过nginx。

所有说我必须留NginX有一个内置的caching,而node.js没有出厂安装(你必须build立自己的文件caching)。 自定义文件caching超越了nginx和市场上其他任何服务器,因为它非常简单。

另外Nginx运行在多个内核上。 要充分利用节点的潜力,您必须对节点服务器进行群集。 如果你有兴趣知道如何,那么请下午。

你需要深挖来达到与节点性能的必杀技,那是唯一的问题。 一旦完成地狱是啊…它击败Nginx。