The comparison of Nginx and Haproxy in Web application

These days I compare nginx and Haproxy, and come to a surprising result.

First, some background information is presented. For a long time, we bengler the Nginx as the main Web server for our project, just as we did under mongrel as a proxy for rails. Nginx is a very good small open source software, it occupies a small space, a reasonable configuration language, advanced features and fast. However, we quickly discovered that the load balancing feature of the agent in Nginx was not satisfactory.

The most important problem is the proxy load balancing algorithm. Nginx only has two load balancers with round robin and source IP hashes, and only the former is of interest to us because our object is to distribute the load evenly across a group of mongrel back-end servers. Round robin load Balancing (ROUND-ROBIN) is acceptable in this case: if each request ends within milliseconds, then no problem.

However, if a page takes a bit longer to load, Nginx will send the request to the backend server that is processing the request-which will cause some back-end servers to queue up the requests while others remain idle. In other words, the load you get is not evenly distributed, and the average is exacerbated by the increase in load.

So when Gzegorz Nosek declared his fair load Balancer module with the support of Engineyard, we would naturally attack it. The Gzegorz module distributes the request to a back-end server with a minimum of outstanding requests, which greatly improves performance.

Unfortunately, the Gzegorz patch is not completely stable and is a major source of our stability problems. And sometimes it stops distributing requests in the back-end server's idle state, and accumulates requests, or worse, becomes chaotic and denies service requests, and the only solution to this situation is to restart Nginx. However, even under normal circumstances, the module will often send multiple requests to the same back-end server, although some other servers are still idle because each of our back-end servers has no limit on the number of connections that can be received.

Since reading the haproxy, I am eager to try this product myself. Haproxy has some very appealing features:

1. It's a proxy--and it's just a proxy. It cannot provide a file, for example: An agent is the only thing it does.

2. It can proxy anything that's based on TCP--not just HTTP.

3. A very high number of load-balancing algorithms, including the "minimum number of connections (least connections)" policy, correlate back-end servers with a minimum number of connections; and that's exactly what we want.

4. The backend can be used only for validity detection through URLs to avoid sending requests to the problematic backend server. (It can even adjust the check time to avoid spikes.) ）

5. Provide a dedicated status page to tell you the status, uptime, and many full metrics of the backend server. Another way is to read the metric from a UNIX domain socket.

6. Requests can be sent through a variety of things: cookies, URL strings, client IPs, and so on.

I really like the way Haproxy is so exclusive. Experience tells me that simple, single-minded, complex dedicated applications are desirable, flexible universal applications; Varnish and memcached are two good examples.

I had to do a simple stress test in order to determine whether Haproxy was a standard. They're not necessarily very scientific, but I think it's enough.

Installation: Dedicated test machine (quad-core AMD64 2.4GHz, 4GB memory), 3 mongrel each running under a real Rails1.2-based app. I use Apache AB as a stress test tool (many people are more inclined to httperf, but we have never seen empathy), and I run 1000 requests in various concurrency situations; The page being tested is a database call with a small controller action, Memcached find and render an empty page at a time; this altogether costs about 20ms.

I have configured the Gzegorz Fair load Balancing patch under Nginx. This configuration will not do anything but provide a proxy for mongrel.

The same is me configuring Haproxy as the minimum number of connections (Leastconns) algorithm, and the maximum number of connections per mongrel (maxconn) is 1. This is a deliberate injustice--but our object is not to compare haproxy and nginx in each configuration, but instead, I want to look at what performance can be achieved by Haproxy's small attempt.

The "Maxconns" configuration is very meaningful-because mongrel can only process a single request at the same time, which means waiting for the client request to be idle within the haproxy-not in mongrel. Then, when a backend is idle, the next request is queued to be allocated to the idle backend. Of course, without this restriction, the request will be distributed to the busy mongrel, and will still be waiting in this back-end server even if there may be other backend idle states.

Nginx with a fair load balancing patch, the behavior will be the same, but occasionally the request is repeated because it does not limit the number of connections that can be received per backend.

Therefore, the data and graphs show the response time for each request.

Figure 1:nginx--Number of concurrent 3

Figure 2:haproxy--Number of concurrent 3

Figure 3:nginx--Number of concurrent 10

Figure 4:haproxy--Concurrency number

Figure 5:nginx--Concurrency number

Figure 6:haproxy--Concurrency number

HAproxy the number of requests above/per second-when the number of concurrent connections is 30 o'clock, we get 218 requests per second, and Nginx is 162 requests per second-but the main difference here is the distribution of response time.

In the concurrency number of 3 is, nginx open processing each request is a bit slow, and haproxy in the concurrency of 10 will still control 95% of the request is processed within the fastest request time. At the same time, nginx performance is still the same as haproxy, unfortunately, this balance of the turning point occurs in the return of a small portion of the connection takes time to be extremely slow.

I'm not sure if Haproxy ordered the request queue; Because the backend is often full, some requests may wait for a long time without being allocated. This also explains the markup on the diagram: I had a request in a test session that took 47 seconds.

I think these results suggest that haproxy is a better choice for us. And its added functionality and fine-grained proxy control are also very popular. Haproxy's lack of support for shared static files means that we will still be erecting nginx after haproxy to handle incoming requests.

1. This article is a translation of the Programmer's architecture

2. This article is translated from affection code article comparing Nginx and HAProxy for Web applications

3. Reprint Please be sure to indicate this article from : Programmer Architecture (No.:archleaner )

4. More articles please scan the code:

The comparison of Nginx and Haproxy in Web application