Mastering Software Load Balancing: Nginx, LVS, and HAProxy Deep Dive

This article provides a comprehensive overview of software load balancing, detailing the architecture, features, performance, and deployment strategies of Nginx, LVS, and HAProxy, and includes practical scenarios for front‑end, internal, and high‑availability setups.

ITFLY8 Architecture Home
ITFLY8 Architecture Home
ITFLY8 Architecture Home
Mastering Software Load Balancing: Nginx, LVS, and HAProxy Deep Dive

Presentation Outline

Software load balancing overview

Nginx load balancing

LVS load balancing

HAProxy load balancing

Summary

1. Software Load Balancing Overview

Hardware load balancers are high‑performance but expensive, so software load balancers such as Nginx, LVS, and HAProxy are widely used on the Internet. This article references many documents, some copied directly.

2. Nginx Load Balancing

Nginx is a lightweight web server / reverse‑proxy that operates at the HTTP layer. It offers high performance, high concurrency, low memory usage, and can handle up to 50,000 concurrent connections.

Supported operating systems: Linux, Windows, FreeBSD, Solaris, macOS, AIX, etc.

Implemented in C.

Officially supports 50,000 concurrent requests per second; typical deployments achieve 20,000, with optimizations reaching 100,000.

2.1 Features

1. Modular design – easy extension via modules.

2. High reliability – master and worker processes synchronize; a failing worker is immediately restarted.

3. Low memory consumption – 10,000 keep‑alive connections use only ~2.5 MB.

4. Hot deployment – configuration can be reloaded without stopping the server.

5. Strong concurrency – up to 50,000 requests per second.

6. Rich functionality – powerful reverse‑proxy and flexible load‑balancing strategies.

2.2 Functions

2.2.1 Basic Functions

Static web serving.

Reverse proxy and load balancing for HTTP, SMTP, POP3.

FastCGI (FPM) support.

Modular filters for compression, SSL, image resizing, etc.

Built‑in health checks.

Name‑ and IP‑based virtual hosts.

Custom access logs.

Smooth upgrades.

Keep‑alive support.

URL rewrite.

Path aliasing.

IP‑ and username‑based access control.

Rate limiting and connection limiting.

2.2.2 Extended Functions

(Content omitted for brevity.)

2.2.3 Performance

Official tests show 50,000 concurrent connections; production environments typically reach 20‑30 k. 10,000 idle keep‑alive connections consume about 2.5 MB. On a 24 GB machine, Nginx can handle up to 2 million concurrent requests.

2.3 Architecture

2.3.1 Basic Working Model

A master process (running as root to bind port 80) spawns one or more worker processes. The master loads configuration and performs graceful upgrades; workers handle the actual request processing. Modules are chained in a pipeline, each performing a specific task such as header parsing, data lookup, or compression.

Hot deployment works by the master reloading the configuration, allowing existing workers to finish current requests before being replaced by new workers with the updated settings.

2.3.2 Sendfile Mechanism

Sendfile lets the kernel transfer file data directly to the network socket, bypassing user‑space copying and reducing overhead, which is essential for high‑concurrency scenarios.

2.3.3 I/O Multiplexing Model

Supports epoll, kqueue, rt signals, /dev/poll, event ports, select, and poll, as well as features like sendfile, AIO, DIRECTIO, accept‑filters, and TCP_DEFER_ACCEPT.

2.4 Load‑Balancing Strategies

Nginx provides built‑in strategies (weighted round‑robin, IP hash) and many extensible ones (fair, generic hash, consistent hash). The following examples use source code from nginx‑1.0.15.

2.4.1 Weighted Round Robin

The algorithm first assigns requests to higher‑weight servers until their weight drops below others, then moves to the next server. If all back‑ends are down, Nginx resets flags to avoid a total timeout.

2.4.2 IP Hash

IP hash distributes requests based on client IP, ensuring the same client is directed to the same backend.

2.4.3 Fair

The fair module selects the backend with the lowest response time, offering strong adaptability but may be unsuitable for unstable networks.

2.4.4 Generic Hash & Consistent Hash

Generic hash uses a variable as the key; consistent hash implements a hash ring, useful for memcached.

2.5 Deployment Scenarios

2.5.1 Front‑End Load Balancing

Nginx sits at the edge, forwarding requests to application servers or a secondary load balancer such as LVS.

2.5.2 Internal Load Balancing

LVS receives external traffic and distributes it to multiple Nginx instances, which then route to specific application servers.

2.5.3 High Availability

Typical HA setup includes two Nginx nodes (master and backup) monitored by Keepalived, sharing a virtual IP (VIP) that clients connect to.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Backendhigh availabilityNginxHAProxyLVS
ITFLY8 Architecture Home
Written by

ITFLY8 Architecture Home

ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.