这几天我对Nginx和HAProxy做了比较，得出了令人吃惊的结果。

首先，介绍一些背景情况。在很长的一段时间里，我们在Bengler把Nginx作为我们项目的主要web服务器，就像在Mongrel下代理Rails运行一样。Nginx是一个非常好的小开源软件，它占用空间小、有合理的配置语言、功能先进而且速度快。然而，我们却很快发现nginx中代理的负载均衡特性却不尽如人意。

这其中最核心的问题是代理负载均衡算法。Nginx仅仅自带轮循和源ip哈希两种负载均衡器；而只有前者是我们感兴趣的,因为我们的对象是将负载均匀地分散到一群Mongrel后端服务器上。轮循负载均衡（round-robin）在这种情况下是可以被接受的：如果每个请求都是在几毫秒之内结束，那么没问题。

但是，如果一个页面在加载时花费时间稍长，Nginx将会把请求发送至正在处理请求的后端服务器中--这将导致，一些后端服务器会排队处理请求，而另一些服务器却仍处于空闲状态。也就是说，你得到的负载没有被均匀分配，而这种不平均会随着负载的增加而加剧。

所以当Gzegorz Nosek在 EngineYard的支持下声明他公平的负载平衡器模块时，我们自然会抨击它。Gzegorz的模块将请求分发至拥有最少未处理请求的后端服务器上，这种做法很大程度上提高的性能。

不幸的是，Gzegorz的补丁不完全稳定，而且成为我们稳定性问题的主要来源。而且有时它会在后端服务器空闲的状态下停止分发请求，并且堆积请求，或者更糟，会变的混乱还会拒绝服务请求；而对于这种情况唯一的解救方案是重启Nginx。然而，即使实在正常情况下，该模块也会经常会将多个请求发送到同一台后端服务器上，尽管其他有些服务器还是空闲的，因为我们每台后端服务器都没有限制可接收连接数的数量。

自从阅读了HAProxy后，我急切的想亲自尝试下这个产品。HAProxy有一些非常吸引人的特性：

1. 它是一个代理--而且只是一个代理。它不能提供文件，例如：代理就是它唯一做的事情。

2. 它可以代理任何基于TCP的东西--而不仅仅是HTTP。

3. 非常多的负载均衡算法，包括“最少连接数（least connections）”策略，将后端服务器和最少连接数关联起来；而这，也正是我们想要的。

4. 后端可以通过URL被只能的做有效性检测用来避免将请求发送至有问题的后端服务器上。（它甚至可以调整检查时机以避开峰值。）

5. 提供专用的状态页来告诉你后端服务器的状态、运行时间以及很多齐全的指标。还有一个方法是从Unix域套接字读取指标。

6. 请求可以通过各种各样的东西发送：cookies、URL字符串、客户端IP，等等。

我非常喜欢HAProxy如此专一的方法。经验告诉我,简单、专一,在复杂的专用应用程序是可取的,灵活的放之四海而皆准的应用程序；Varnish 和Memcached就是两个很好的例子。

为了确定HAProxy是否达标，我不得不做一个简单的压力测试。它们不一定非常科学，但是我觉得这已经够用了。

安装：专门的测试机器（四核AMD64 2.4GHz, 4GB内存），3个mongrel每个下面跑一个真实的基于Rails1.2的app。我使用Apache ab作为压力测试工具（许多人更倾向于httperf,但我们从未见过心有灵犀），而且我在各种并发情况下各跑1000个请求；被测试的页面是通过一个小的控制器action来做一个数据库调用、一次Memcached查找以及渲染一个空页面；这总共话花费20ms左右。

我已经在Nginx下配置了Gzegorz的公平负载均衡补丁。这个配置除了为Mongrel提供代理外不会做任何事情。

同是我配置HAProxy为“最小连接数（leastconns）”算法，而且每个Mongrel的最大连接数（maxconn）为1。这是故意配置的不公平--但我们的对象不是比较HAProxy和Nginx在每个配置相同时的情况；相反，我想观察的是通过HAProxy的小尝试可以获得什么样的性能情况。

“maxconns”配置是非常有意义的--由于Mongrel在同一时刻只能处理一个单独的请求，这意味着等待客户端请求在HAProxy内部空闲--而不是在Mongrel中。随后，当一个后端空闲下来时，下一个请求将排成线被分配到空闲的后端。当然，没有这个限制的话，请求将被分发到繁忙中的Mongrel，而且即使有可能有其他后端处于空闲状态也仍然会在这台后端服务器中等待。

Nginx使用公平负载均衡补丁，行为将相同，但是偶尔会重复请求,因为它没有限制每个后端可以接收的连接数量。

因此，一下这些数据、图展示了每个请求的响应时间。

图1：nginx--并发数3

图2：HAProxy--并发数3

图3：nginx--并发数10

图4：HAProxy--并发数10

图5：nginx--并发数30

图6：HAproxy--并发数30

HAproxy得出以上的请求数/每秒--在并发连接数为30时，我们得到218请求/秒，而nginx为162请求/秒--但是，这里最主要的不同是在响应时间上的分布。

在并发数为3是，nginx开处理每个请求有点慢，而HAProxy在并发数为10时仍会控制95%的请求在最快的请求时间内被处理。与此同时，Nginx的性能虽然表现的仍然和HAProxy相当；不幸的是，这种平衡的转折点发生在返回的一小部分连接花费时间上极其缓慢。

我不确定HAProxy是否对请求队列做了强制排序；由于后端往往是满的，也许一些请求会等待很长时间而没有被分配处理。这点也解释了图上的标记：在一个测试会话中我有一个请求花了47秒。

我认为这些结果显示HAProxy对我们来说是一个更好的选择。而且它的附加功能和细粒度的代理控制也非常受欢迎。而HAProxy缺乏对共享静态文件支持意味着我们仍然会在HAProxy之后架设Nginx来应对路由进来的请求。

1.本文由程序员学架构摘译

2. 本文译自Affection Code文章Comparing Nginx and HAProxy for web applications

3. 转载请务必注明本文出自：程序员学架构(微信号：archleaner )

4. 更多文章请扫码：

Nginx与HAProxy在web应用中的比较