Master High-Concurrency Nginx: Core Configs, Advanced Tuning, and Real-World Checklist
This guide walks you through the common high‑traffic pain points of Nginx, explains why configuration and tuning matter more than hardware, and provides step‑by‑step core, advanced, OS‑level, monitoring, and troubleshooting configurations to reliably handle tens of thousands of concurrent connections.
Part 1: Core Nginx Configuration Optimization
When traffic spikes, many operations teams encounter 502/504 errors, CPU saturation, connection limits, and sluggish response times. The root cause is often mis‑configured Nginx rather than hardware limitations.
1. Worker processes and connections
# 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;
# limit on open files per worker
worker_rlimit_nofile 100000;2. Event‑driven model
events {
# use epoll on Linux (best choice)
use epoll;
# accept multiple connections simultaneously
multi_accept on;
# set maximum connections
worker_connections 65535;
# disable accept mutex for faster accept
accept_mutex off;
}3. HTTP core settings
http {
# efficient file transfer
sendfile on;
tcp_nopush on;
tcp_nodelay on;
# keep‑alive timeout and request limits
keepalive_timeout 60;
keepalive_requests 10000;
client_header_timeout 10;
client_body_timeout 10;
send_timeout 10;
# buffer sizes
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 2: Advanced Performance Optimizations
1. Connection pool and caching
http {
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;
}
# open 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;
}2. Rate limiting and protection
http {
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;
server {
# apply rate limits
limit_req zone=api burst=200 nodelay;
limit_conn perip 20;
limit_conn perserver 2000;
# long‑term caching for static assets
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# API optimization
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 3: OS Kernel Parameter Tuning
High‑concurrency also requires kernel‑level tweaks.
# /etc/sysctl.conf additions
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 30000
net.core.rmem_default = 262144
net.core.rmem_max = 16777216
net.core.wmem_default = 262144
net.core.wmem_max = 16777216
# TCP settings
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
# Connection tracking table size
net.netfilter.nf_conntrack_max = 1048576
net.nf_conntrack_max = 1048576
# File descriptor limits
fs.file-max = 1048576
# Apply changes
sysctl -pAdjust user limits for processes and open files:
# /etc/security/limits.conf additions
* soft nofile 1048576
* hard nofile 1048576
* soft nproc 1048576
* hard nproc 1048576
nginx soft nofile 1048576
nginx hard nofile 1048576Part 4: Real‑World Monitoring and Tuning
1. Monitoring script
#!/bin/bash
# nginx_monitor.sh – Nginx performance monitor
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 list ==="
ps aux | grep nginx | grep -v grep
echo "=== System load ==="
uptime
echo "=== Memory usage ==="
free -h
echo "=== Nginx status page ==="
curl -s http://localhost/nginx_status2. Load testing commands
# wrk stress test
wrk -t20 -c1000 -d60s --latency http://your-domain.com/
# ApacheBench test
ab -n 100000 -c 1000 http://your-domain.com/
# Monitor Nginx processes during test
top -p $(pgrep nginx | tr '
' ',' | sed 's/,$//')Part 5: High‑Concurrency Architecture Best Practices
1. Multi‑layer caching 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;
}2. Load‑balancing strategy
upstream backend {
# consistent hashing for session stickiness
hash $remote_addr consistent;
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;
server 192.168.1.102:8080 weight=2 max_fails=3 fail_timeout=30s backup;
}Part 6: Troubleshooting Checklist
CPU cores match worker_processes File descriptor limits increased
Kernel network parameters tuned
Appropriate caching strategies enabled
Reasonable timeout values configured
Rate‑limiting measures in place
Monitoring system deployed
Conclusion
After applying the above comprehensive optimizations, your Nginx instance should be able to support 100k+ concurrent connections, keep response times under 100 ms, maintain CPU usage within acceptable bounds, and use memory more efficiently. Remember to reload the configuration ( nginx -s reload) and verify the impact in a staging environment before production rollout.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architect
Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
