Mastering Load Balancing: When to Choose LVS, Nginx, or HAProxy

Most internet systems today rely on server clusters, deploying identical services across multiple machines to form a unified service, whether for web applications, databases, or distributed caches.

Before a web server cluster, a load‑balancing server receives client traffic, selects the most suitable web server, and forwards the request, achieving transparent client‑to‑backend communication.

Cloud computing and distributed architectures essentially package backend servers as a single, seemingly limitless service, while the real work is performed by the underlying cluster.

LVS, Nginx, and HAProxy are the three most widely used load‑balancing software solutions.

Choosing a load balancer depends on site scale: small sites (PV < 10 million) can use Nginx; medium sites may use DNS round‑robin or LVS; large, critical services often adopt LVS.

A common architecture is: front‑end Nginx/HAProxy + Keepalived as the load balancer; back‑end MySQL master‑slave with read/write separation, combined with LVS + Keepalived.

LVS

LVS (Linux Virtual Server) is now part of the standard Linux kernel (since 2.4) and requires no patches.

Since 1998, LVS has matured into a stable technology.

1. LVS Architecture

The LVS cluster consists of three layers:

Load Balancer layer (front‑end)

Server Array layer (middle)

Shared Storage layer (bottom)

2. LVS Load‑Balancing Mechanism

LVS operates at the transport layer (Layer 4), handling TCP/UDP traffic. Unlike Layer 7 solutions such as HAProxy, it cannot parse HTTP URLs, but its Layer 4 nature gives it very high efficiency.

Four‑layer balancing uses destination address and port; seven‑layer balancing (content switching) uses application‑layer data.

3. NAT Mode

In NAT mode, LVS acts as a gateway for real servers (RS). It performs Destination NAT (DNAT) to replace the client‑destined IP with the RS IP, and Source NAT (SNAT) to replace the RS source IP with the virtual IP (VIP) before sending the response back to the client.

4. DR Mode (Direct Routing)

DR mode binds the same VIP to both LVS and RS. LVS only rewrites the MAC address to forward packets to a chosen RS; IP addresses remain unchanged, allowing the RS to reply directly to the client, which eliminates the load balancer as a bottleneck.

5. Advantages of LVS

Strong load capacity; operates at Layer 4 with minimal CPU and memory usage.

Low configuration complexity, reducing human error.

High stability with built‑in hot‑standby (e.g., LVS + Keepalived).

Pure request forwarding without generating traffic, preserving I/O performance.

Broad applicability to HTTP, databases, chat services, etc.

6. Disadvantages of LVS

Cannot process regular expressions; lacks content‑switching capabilities.

Complex to deploy DR + Keepalived for large applications compared with Nginx/HAProxy + Keepalived.

Nginx

Nginx is a high‑performance web server and reverse proxy that excels at handling massive concurrent HTTP requests.

1. Nginx Architecture

Unlike process‑oriented servers (e.g., Apache), Nginx uses an event‑driven, asynchronous, single‑threaded model. It runs a master process and multiple worker processes that share memory, handling many connections with epoll‑based multiplexing.

2. Nginx Load Balancing

Nginx performs load balancing at the application layer (Layer 7) via reverse proxy. Supported upstream strategies include:

Round‑robin (default)

Weight (proportional to server capacity)

ip_hash (client IP based persistence)

fair (third‑party, based on response time)

url_hash (third‑party, URL‑based persistence)

3. Advantages of Nginx

Cross‑platform support (Unix‑like OS and Windows)

Simple configuration

Non‑blocking, high‑concurrency handling (tens of thousands of connections)

Event‑driven architecture with master/worker model

Low memory consumption (≈15 MB per worker)

Built‑in health checks

Bandwidth saving via GZIP compression and caching headers

High stability as a reverse proxy

4. Disadvantages of Nginx

Only supports HTTP, HTTPS, and email protocols

Health checks are port‑based, not URL‑based

No native session persistence (can be mitigated with ip_hash)

HAProxy

HAProxy supports both TCP (Layer 4) and HTTP (Layer 7) proxy modes and virtual hosting.

Its strengths complement Nginx, offering session persistence, cookie‑based routing, and URL health checks.

Performance‑wise, HAProxy often outperforms Nginx in raw load‑balancing speed and handles high concurrency efficiently.

HAProxy can also balance MySQL traffic and perform health checks on backend MySQL nodes, often used together with LVS + Keepalived for database replication setups.

Supported load‑balancing algorithms include round‑robin, weighted round‑robin, source (IP‑preserve), request‑URL, and rdp‑cookie.

Reference:

https://zhongwuzw.github.io

http://www.importnew.com/11229.html

http://edisonchou.cnblogs.com