Nginx Load Balancing: Weighted Round Robin, IP Hash, Fair & Consistent Hash

This article examines nginx’s built‑in and extended load‑balancing algorithms—including weighted round‑robin, IP hash, fair, generic hash and consistent hash—by dissecting source code, describing implementation details, and presenting comparative performance tests that evaluate balance, consistency and fault‑tolerance across various scenarios.

21CTO
21CTO
21CTO
Nginx Load Balancing: Weighted Round Robin, IP Hash, Fair & Consistent Hash

1. Introduction

For large‑scale websites, load balancing remains a critical topic. While hardware load balancers such as F5 BIG‑IP, Citrix NetScaler, and Radware offer powerful features, their high cost drives many companies to adopt software solutions. Nginx, originally a web server, has gained widespread attention for its reverse‑proxy capabilities and flexible load‑balancing strategies. This article uses an industrial production background to discuss the design, implementation, and practical application of Nginx load‑balancing policies.

2. Source Code Analysis

Nginx’s load‑balancing strategies are divided into built‑in and extended categories. Built‑in strategies (weighted round‑robin and IP hash) are compiled into the Nginx core by default, while extended strategies (fair, generic hash, consistent hash) are optional modules.

2.1 Weighted Round Robin

The weighted round‑robin algorithm first distributes requests to higher‑weight servers until their weight drops below that of other servers, then moves to the next server. When all back‑ends are down, Nginx resets the state flags to avoid a total timeout.

The relevant source files are ngx_http_upstream_round_robin.c and ngx_http_upstream_round_robin.h. Key structures include current_weight (dynamic during request handling) and weight (static configuration). The creation process uses a bitmap tried to track which servers have been attempted.

The final strategy code is concise, about 30 lines:

2.2 IP Hash

IP hash is another built‑in strategy. It hashes the client IP together with the number of back‑ends to select a server. If the hash fails after 20 attempts, it falls back to round‑robin.

2.3 Fair

Fair is an extended strategy that selects the server with the lowest response time, offering strong adaptability but requiring careful testing in complex network environments.

2.4 Generic Hash & Consistent Hash

Both are extended strategies. Generic hash uses a configurable key for hashing, while consistent hash employs a hash ring that can support services like memcached. When a server goes down, generic and consistent hash lose the traffic destined for that server, whereas IP hash degrades gracefully to round‑robin.

3. Comparative Tests

3.1 Test Tools

easyABC – an internal performance testing tool capable of generating tens of thousands of requests.

polygraph – a free tool that tests caching, proxy, and switch performance using a configurable language (PGL).

3.2 Test Environment

The tests run on five physical machines: one 8‑core server hosts the Nginx instance under test, while four 4‑core machines run easyABC, the web‑server stubs, and polygraph.

3.3 Test Plan

Key metrics: balance (even request distribution), consistency (same key maps to same server), and fault tolerance (operation when some back‑ends fail). Four scenarios were executed:

Scenario 1: all servers operational.

Scenario 2: server_4 down.

Scenario 3: server_3 and server_4 down.

Scenario 4: all servers restored.

Each scenario builds on the previous one without restarting the Nginx instance. easyABC generated ~17,000 QPS, polygraph ~4,000 QPS.

3.4 Test Results

Round‑robin performed well in both balance and fault tolerance, as shown in Table 1 and Figure 1 (identical results for both tools).

Fair showed large variance and poor balance, though its adaptability may be beneficial in certain network conditions.

Generic hash and consistent hash suffered from traffic loss when a back‑end failed, whereas IP hash fell back to round‑robin, avoiding loss.

Real‑world IP hash traffic (Figure 5) demonstrated significant imbalance due to high‑volume IP sources (e.g., university and enterprise gateways) overwhelming the algorithm.

4. Conclusion and Outlook

Through source‑code inspection and empirical testing, we evaluated Nginx’s load‑balancing strategies across balance, consistency, fault tolerance, and suitable scenarios. No single strategy fits all cases; selection depends on the specific workload and the operator’s familiarity with each algorithm. The analysis and data aim to help practitioners choose the most appropriate strategy for their environments.

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.

load balancingPerformance TestingNginxIP HashWeighted Round Robin
21CTO
Written by

21CTO

21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.

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.