Master High‑Concurrency Nginx: Core, Advanced, and OS Tuning Guide

Why Nginx Fails Under High Concurrency

When traffic surges, many operators encounter 502/504 errors, CPU usage spikes without throughput gains, connection limits being hit, and increasingly slow response times. These problems usually stem from sub‑optimal configuration rather than hardware.

Part 1 – Core Nginx Configuration

# Number of worker processes = number of CPU cores
worker_processes auto;
# Maximum connections per worker
worker_connections 65535;
# Worker priority (‑20 highest, 20 lowest)
worker_priority -10;
# CPU affinity to avoid context switches
worker_cpu_affinity auto;
# Open file descriptor limit per worker
worker_rlimit_nofile 100000;

Part 2 – Event Model Optimization

events {
    # Use epoll on Linux (best performance)
    use epoll;
    # Accept multiple connections simultaneously
    multi_accept on;
    # Connection limit (already set in core)
    worker_connections 65535;
    # Disable accept mutex for faster accept
    accept_mutex off;
}

Part 3 – HTTP Core Settings

http {
    # Efficient file transfer
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Connection timeout settings
    keepalive_timeout 60;
    keepalive_requests 10000;
    client_header_timeout 10;
    client_body_timeout 10;
    send_timeout 10;

    # Buffer size optimizations
    client_header_buffer_size 4k;
    large_client_header_buffers 8 8k;
    client_body_buffer_size 128k;
    client_max_body_size 50m;

    # Enable gzip compression
    gzip on;
    gzip_vary on;
    gzip_min_length 1000;
    gzip_comp_level 6;
    gzip_types text/plain text/css text/javascript application/javascript application/json application/xml;

    # Hide Nginx version
    server_tokens off;
}

Part 4 – Advanced Performance Settings

# Connection pool
upstream backend {
    keepalive 300;
    keepalive_requests 10000;
    keepalive_timeout 60s;
    server 192.168.1.100:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.101:8080 weight=2 max_fails=3 fail_timeout=30s;
}

# File cache
open_file_cache max=100000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

# FastCGI cache (for PHP)
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=fcgi:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;

Part 5 – Rate Limiting and Protection

# Request rate limits
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;

# Connection limits
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;

server {
    # Apply rate‑limit rules
    limit_req zone=api burst=200 nodelay;
    limit_conn perip 20;
    limit_conn perserver 2000;

    # Long‑term static asset caching
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # API proxy with rate limiting
    location /api/ {
        limit_req zone=api burst=50 nodelay;
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_connect_timeout 5s;
        proxy_send_timeout 10s;
        proxy_read_timeout 10s;
    }
}

Part 6 – Multi‑Level Cache Strategy

# L1: Nginx local cache
location / {
    try_files $uri @proxy;
}

# L2: Proxy cache
location @proxy {
    proxy_cache my_cache;
    proxy_cache_valid 200 302 1h;
    proxy_cache_valid 404 1m;
    proxy_pass http://backend;
    # Cache lock to prevent stampede
    proxy_cache_lock on;
    proxy_cache_lock_timeout 5s;
}

Part 7 – Load‑Balancing Strategy

upstream backend {
    # Consistent hash for session stickiness
    hash $remote_addr consistent;
    # Health check (requires nginx‑plus or third‑party module)
    server 192.168.1.100:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.101:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.102:8080 weight=2 max_fails=3 fail_timeout=30s backup;
}

Part 8 – Fault Diagnosis & Performance Checklist

Match CPU core count with worker_processes Increase worker_connections as needed (each connection ~232‑248 B memory)

Raise file descriptor limits (e.g., fs.file-max 1048576)

Tune kernel network parameters (e.g., net.core.somaxconn 65535, TCP settings)

Enable appropriate caching and gzip settings

Apply request rate‑limiting and connection limits

Deploy monitoring scripts (see Part 9)

Part 9 – Monitoring Scripts

#!/bin/bash
# nginx_monitor.sh – Nginx performance monitoring

echo "=== Nginx connection status ==="
ss -s

echo "=== Active connections ==="
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

echo "=== Nginx process status ==="
ps aux | grep nginx | grep -v grep

echo "=== System load ==="
uptime

echo "=== Memory usage ==="
free -h

echo "=== Nginx access stats ==="
curl -s http://localhost/nginx_status

Part 10 – Performance Testing Commands

# wrk load test
wrk -t20 -c1000 -d60s --latency http://your-domain.com/

# ApacheBench test
ab -n 100000 -c 1000 http://your-domain.com/

# Monitor Nginx processes
top -p $(pgrep nginx | tr '
' ',' | sed 's/,$//')

Conclusion

After applying the above configurations, your Nginx server should be able to handle 100 k+ concurrent connections, keep response times under 100 ms, maintain reasonable CPU usage, and use memory efficiently. Remember that performance tuning is iterative; always validate changes in a staging environment before rolling them out to production.