巨头之间的终极对决：崛起的新星 node.js 能否战胜巨人 apache 和 nginx？
我和你一样，都阅读过大量散布在互联网各处的意见或事实，其中有一些我认为是可靠的，而其它的可能是谣传，让人难以置信。
起初，我做了一些思想准备，我认为我可以避免自己进行实际测试来校验结论的麻烦——在我知道这一切之前我一直这样认为。
尽管如此，回顾之前，似乎我最初的想法是相当准确的，并且被我的测试再次印证。这个事实让我想起了当年我在学校学到的爱因斯坦和他的光电效应的实验，他面临着一个光的波粒二重性的问题，最初的结论是实验受到他的心理状态的影响，即当他期望结果是一个波的时候结果就会是一个波，反之亦然。
也就是说，我坚信我的结果不会在不久的将来被证明二重性，虽然我的心理状态可能在某种程度上对它们有影响。
<a target="_blank"></a>
上面我读过一份材料具有一种革新的方式，在我看来，需要了解其自然而然的主观性和作者自身的偏见。
我决定采用这种方式，因此，提前声明以下内容：
开发者花了很多年来打磨他们的作品。那些取得了更高成就的人通常参考很多因素来做出自己的抉择，这是主观的做法；你需要推崇和捍卫你的技术决策。
也就是说，这个比较文章的着眼点不会成为另一篇“哥们，使用适合你的东西就好”的口水文章。我将会根据我的自身经验、需求和偏见提出建议。你可能会同意其中一些观点，反对另外一些；这很好——你的意见会帮助别人做出明智的选择。
所有的测试都在本地运行：
英特尔酷睿 i7-2600k，四核八线程的机器
用于基准测试的工具：apachebench，2.3 <$revision: 1748469 $>
测试包括一系列基准，从 1000 到 10000 个请求以及从 100 到 1000 个的并发请求——结果相当令人惊讶。
此外，我还进行了在高负载下测量服务器功能的压力测试。
至于内容，主要是一个包含一些 lorem ipsum 的标题和一张图片静态文件。
lorem ipsum 和 apachebenchmark
我决定专注于静态文件的原因是因为它们去除了可能对测试产生影响的各种渲染因素，例如：编程语言解释器的速度、解释器与服务器的集成程度等等。
此外，基于我自身的经验，平均网页加载时间很大一部分通常花费在静态内容上，例如图片，因此关注哪个服务器可以节省我们加载静态内容的时间是比较现实的。
除此之外，我还想测试一个更加真实的案例，案例中我在运行不同 cms 的动态页面（稍后将详细介绍）时对服务器进行基准测试。
正如我用的是 gentoo linux，你就知道我的 http 服务器在一开始就已经经过优化了，因为我在构建系统的时候只使用了我实际需要的东西。也就是说，当我运行我的测试的时候，不会在后台运行任何不必要的代码或加载没用的模块。
apache、nginx 和 node.js 的使用的配置对比
<code>$: curl -i http://localhost/index.html</code>
<code></code>
<code>http/1.1 200 ok</code>
<code>date: sun, 30 oct 2016 15:35:44 gmt</code>
<code>server: apache</code>
<code>last-modified: sun, 30 oct 2016 14:13:36 gmt</code>
<code>etag: "2cf2-54015b280046d"</code>
<code>accept-ranges: bytes</code>
<code>content-length: 11506</code>
<code>cache-control: max-age=600</code>
<code>expires: sun, 30 oct 2016 15:45:44 gmt</code>
<code>vary: accept-encoding</code>
<code>content-type: text/html</code>
apache 配置了 “event mpm”。
<code>server: nginx/1.10.1</code>
<code>date: sun, 30 oct 2016 14:17:30 gmt</code>
<code>connection: keep-alive</code>
<code>keep-alive: timeout=20</code>
<code>etag: "58160010-2cf2"</code>
nginx 包括几个调整：<code>sendfile on</code>、<code>tcp_nopush on</code> 和 <code>tcp_nodelay on</code>。
<code>$: curl -i http://127.0.0.1:8080</code>
<code>etag: 15</code>
<code>last-modified: thu, 27 oct 2016 14:09:58 gmt</code>
<code>date: sun, 30 oct 2016 16:39:47 gmt</code>
在静态测试中使用的 node.js 服务器是从头定制的，这样可以让它尽可能更加的轻快——没有使用外部模块（node 核心模块除外）。
点击图片以放大：
apache、nginx 与 node 的对比：请求负载的性能（每 100 位并发用户）
apache、nginx 与 node 的对比：用户负载能力（每 1000 个请求）
apache、nginx 与 node 的对比：完成 1000 位用户并发的 100000 个请求耗时
从以上结果判断，似乎 nginx 可以在最少的时间内完成最多请求，换句话来说，nginx 是最快的 http 服务器。
还有一个相当惊人的事实是，在特定的用户并发数和请求数下，node.js 可以比 nginx 和 apache 更快。
但当请求的数量在并发测试中增加的时候，nginx 将重回领先的位置，这个结果可以让那些陷入 node.js 的遐想的人清醒一下。
和 apache、nginx 不同的是，node.js 似乎对用户的并发数不太敏感，尤其是在集群节点。如图所示，集群节点在 0.1 秒左右保持一条直线，而 apache 和 nginx 都有大约 0.2 秒的波动。
基于上述统计可以得出的结论是：网站比较小，其使用的服务器就无所谓。然而，随着网站的受众越来越多，http 服务器的影响变得愈加明显。
当涉及到每台服务器的原始速度的底线的时候，正如压力测试所描述的，我的感觉是，性能背后最关键的因素不是一些特定的算法，而实际上是运行的每台服务器所用的编程语言。
由于 apache 和 nginx 都使用了 c 语言—— aot 语言（编译型语言），而 node.js 使用了 javascript ——这是一种 jit 语言（解释型语言）。这意味着 node.js 在执行程序的过程中还有额外的工作负担。
这意味着我不能仅仅基于上面的结果来下结论，而要做进一步校验，正如你下面看到的结果，当我使用一台经过优化的 node.js 服务器与流行的 express 框架时，我得到几乎相同的性能结论。
逝者如斯夫，如果没有服务的内容，http 服务器是没什么用的。因此，在比较 web 服务器的时候，我们必须考虑的一个重要的部分就是我们希望在上面运行的内容。
虽然也有其它的功能，但是 http 服务器最广泛的使用就是运行网站。因此，为了看到每台服务器的性能的实际效果，我决定比较一下世界上使用最广泛的 cms（内容管理系统）wordpress 和 ghost —— 内核使用了 javascript 的一颗冉冉升起的明星。
基于 javascript 的 ghost 网页能否胜过运行在 php 和 apache / nginx 上面的 wordpress 页面？
这是一个有趣的问题，因为 ghost 具有操作工具单一且一致的优点——无需额外的封装，而 wordpress 需要依赖 apache / nginx 和 php 之间的集成，这可能会导致显著的性能缺陷。
除此之外，php 距 node.js 之间还有一个显著的性能落差，后者更佳，我将在下面简要介绍一下，可能会出现一些与初衷大相径庭的结果。
为了比较 wordpress 和 ghost，我们必须首先考虑一个影响到两者的基本组件。
基本上，wordpress 是一个基于 php 的 cms，而 ghost 是基于 node.js（javascript）的。与 php 不同，node.js 有以下优点：
非阻塞的 i/o
事件驱动
更新颖、更少的残旧代码
由于有大量的测评文章解释和演示了 node.js 的原始速度超过 php（包括 php 7），我不会再进一步阐述这个主题，请你自行用谷歌搜索相关内容。
因此，考虑到 node.js 的性能优于 php，一个 node.js 的网站的速度要比 apache / nginx 和 php 的网站快吗？
当比较 wordpress 和 ghost 时，有些人会说这就像比较苹果和橘子，大多数情况下我同意这个观点，因为 wordpress 是一个完全成熟的 cms，而 ghost 基本上只是一个博客平台。
然而，两者仍然有共同竞争的市场，这两者都可以用于向世界发布你的个人文章。
制定一个前提，我们怎么比较两个完全基于不同的代码来运行的平台，包括风格主题和核心功能。
事实上，一个科学的实验测试条件是很难设计的。然而，在这个测试中我对更接近生活的情景更感兴趣，所以 wordpress 和 ghost 都将保留其主题。因此，这里的目标是使两个平台的网页大小尽可能相似，让 php 和 node.js 在幕后斗智斗勇。
由于结果是根据不同的标准进行测量的，最重要的是尺度不一样，因此在图表中并排显示它们是不公平的。因此，我改为使用表：
node、nginx、apache 以及运行 wordpress 和 ghost 的比较。前两行是 wordpress，底部的两行是 ghost
正如你所见，尽管事实上 ghost（node.js）正在加载一个更小的页面（你可能会惊讶 1kb 可以产生这么大的差异），它仍然比同时使用 nginx 和 apache 的 wordpress 要慢。
此外，使用 nginx 代理作为负载均衡器来接管每个 node 服务器的请求实际上会提升还是降低性能？
那么，根据上面的表格，如果说它产生什么效果的话，它造成了更慢的效果——这是一个合理的结果，因为额外封装一层理所当然会使其变得更慢。当然，上面的数字也表明这点差异可以忽略不计。
但是上表中最重要的一点是，即使 node.js 比 php 快，http 服务器的作用也可能超过某个 web 平台使用的编程语言的重要性。
当然，另一方面，如果加载的页面更多地依赖于服务器端的脚本处理，那么我怀疑结果可能会有点不同。
最后，如果一个 web 平台真的想在这场竞赛里击败 wordpress，从这个比较中得出的结论就是，要想性能占优，必须要定制一些像 php-fpm 的工具，它将直接与 javascript 通信（而不是作为服务器来运行），因此它可以完全发挥 javascript 的力量来达到更好的性能。
原文发布时间为：2017-11-30
本文来自云栖社区合作伙伴“linux中国”