面向世界非 Twitter 的低延迟 Web 服务器/负载均衡器答案

【问题标题】：Low latency web server/load balancer for the non-Twitters of the world面向世界非 Twitter 的低延迟 Web 服务器/负载均衡器
【发布时间】：2011-12-29 17:33:15
【问题描述】：

多年来，Apache httpd 为我做得很好，在我一直在维护的传统自定义 LAMP 堆栈应用程序中坚如磐石和高性能（阅读：试图逃避）

我的 LAMP 堆栈日子现在已经屈指可数了，我正在进入美妙的多语言世界：

1) Scala REST framework on Jetty 8 (on the fence between Spray & Scalatra)
2) Load balancer/Static file server: Apache Httpd, Nginx, or ?
3) MySQL via ScalaQuery
4) Client-side: jQuery, Backbone, 320 & up or Twitter Bootstrap

选项#2 是这个问题的重点。我看到的基准测试表明，Nginx、Lighthttpd、G-WAN（尤其是）和朋友在性能方面击败了 Apache，但在 Web 服务器处理许多同时连接的高负载场景中，这种打击似乎更多地表现出来.鉴于我们的服务器每月最大带宽为 100GB，平均负载约为 0.10，因此高负载场景显然不适用。

基本上，我需要与应用程序服务器 (Jetty) 的连接和 Web 服务器的静态文件传递既可靠又快速。最后，Web 服务器应该兼作应用服务器的负载平衡器（不需要 SSL，服务器位于 ASA 后面）。我不确定 Apache Httpd 与其他替代方案相比有多快，但它是经过验证的、经过公路勇士测试的软件。

那么，如果我使用 Nginx 或其他 Apache 替代品，在可见性能方面会有什么不同吗？我假设不是，而是为了实现近乎即时的页面加载，把问题放在那里;-)

【问题讨论】：

标签： apache nginx jetty load-balancing latency

【解决方案1】：

如果我使用 Nginx 或其他 Apache 替代品，在可见性能方面会有什么不同吗？

是的，主要是在延迟方面。

根据 Google（他们可能对延迟有所了解），延迟对于用户体验、高搜索引擎排名以及在高负载（成功、脚本小子、真实攻击等）中的生存都很重要。 .

但是在多核上扩展和/或使用更少的 RAM 和 CPU 资源不会受到伤害 - 这就是这些 Web 服务器替代方案的目的。

我看到的基准测试表明，Nginx、Lighthttpd、G-WAN（尤其是）和朋友在性能方面击败了 Apache，但是在 Web 服务器正在处理的高负载场景中，这种打击似乎更多地表现出来许多同时连接

基准测试表明，即使客户端数量很少，一些服务器也比其他服务器更快：here are compared Apache 2.4, Nginx, Lighttpd, Varnish, Litespeed, Cherokee and G-WAN。

由于该测试是由独立于这些服务器作者的人进行的，因此这些测试（使用虚拟化和 1、2、4、8 CPU 内核进行）具有明显的价值。

【讨论】：

+1，不错的基准测试，在性能方面看起来与之前的基准测试几乎相同，显示 GWAN 将其他所有人和 Apache 排在了底部。话虽如此，对于那里的绝大多数低负载站点，很可能人们不会注意到 GWAN 提供 100 字节文件（即基准中使用的文件）和 Apache 提供相同服务之间的最细微差别。值得注意的是，作者在第一句话中提到这是他尝试的第一个基准测试；-) Nginx 是 Apache 在 Web 服务器市场上的主导地位的最大威胁（GWAN 远非免费）
您可能会从了解为什么延迟很重要中受益。然后，G-WAN 对您来说（很多）意义——即使在低频率网站上也是如此。如果基准测试初学者（但网络专业人士）觉得需要测试 G-WAN 与其他服务器，这是一个相当好的迹象。而且 Nginx 的硬件成本比 G-WAN 高得多。 =)
好吧，此时我更关心的是网络延迟，而不是我的堆栈中的延迟。大多数网站都可以使用运行编写不佳的 LAMP 堆栈应用程序的低端服务器。负载极重的站点是例外，在那里选择的堆栈和编码专业知识水平显然至关重要。 G-WAN 有一个利基市场，你们会做得很好，但不开源可能会减慢整个网络服务器市场产品的速度。 Apache、Nginx 等人可能没有抱怨......
G-WAN 不会尝试复制 Nginx 或 Apache：它是为做其他人无法做的事情而编写的。如果您对这些工具感到满意，那么没有理由像您坚持这样做那样批评 G-WAN。

【解决方案2】：

会有很大的不同。 Nginx 与 Apache 一起为超过零并发用户的任何东西抹去地板。假设您正确配置了所有内容。查看以下链接以获得深入了解它的一些帮助。

http://wiki.nginx.org/Main

http://michael.lustfield.net/content/dummies-guide-nginx

http://blog.martinfjordvald.com/2010/07/nginx-primer/

您会看到每秒请求数方面的改进，但您也会看到 RAM 和 CPU 使用率显着减少。我喜欢的一件事是通过更简单的配置更好地控制正在发生的事情。

Apache 声称 apache 2.4 将提供与 nginx 一样好或更好的性能。他们提出了一个大胆的声明，呼吁使用 nginx，当他们发布这个版本时，它有点让他们大吃一惊。当然，它们更接近了，但 nginx 仍然在几乎每一个基准测试中都表现出色。

【讨论】：

谢谢，我有疑问。为什么？ 1) Apache 2.4 已经发布； 2) 谷歌 mod_pagespeed 尚不支持 nginx（不久将扩展到 v2.2 至 v2.4 对 Apache 的支持）。仅 mod_pagespeed 就有足够的理由留在原地； 2.4似乎也在燃烧。如果我只是提供静态内容，我可能会考虑切换，但面向应用程序服务器，坚持使用 Apache。
当我打字时，我也在考虑动态内容。就个人而言，我喜欢控制一切。不过，听起来您实际上并不想使用 Nginx。谷歌搜索 Nginx 与 Apache 将为您提供大量基准。它也非常适合资源较少的小型服务器。除非您真正尝试并确保配置正确，否则您永远不会真正知道哪个更好。
我其实很喜欢nginx的效率，配置确实比Apache的简单多了。然而，虽然 Apache 2.4 在基准测试中可能与 nginx 不太匹配，但我们大多数人都没有足够的运气来处理基准级别的流量。换句话说，就最终用户而言，在速度方面可能存在零差异。这就是为什么我将这篇文章命名为“世界上的非 Twitter”。我正在寻找的不仅仅是原始速度，它是可靠地对应用程序服务器进行负载平衡，可以说在相对低负载的情况下两者中更重要
@virtualyese：一旦您开始生成动态内容（现在几乎所有地方都是这种情况），性能将产生巨大的影响 - 特别是在小型机器上（嵌入式、小型 VPS 实例、旧硬件等），因为垂直扩展比水平扩展成本要低得多，而且对于某些应用程序来说，水平扩展根本不可能。