How do you optimize Nginx performance for high traffic?
Learn to tune Nginx for high traffic: worker processes, keepalive, caching, gzip and HTTP/2, with config examples and common interview questions and answers.
Expected Interview Answer
You optimize Nginx for high traffic by tuning worker processes and connections to match CPU and file-descriptor limits, enabling keepalive and caching, offloading static assets, and compressing responses so each core serves the maximum concurrent requests with minimal latency.
The core levers are event-loop efficiency and avoiding wasted work. Set worker_processes to auto (one per core), raise worker_connections and the OS file-descriptor limit, and enable keepalive on both client and upstream connections to avoid TCP setup costs. Add proxy or FastCGI caching to serve repeat requests without hitting the backend, turn on gzip or brotli, use sendfile and tcp_nopush for zero-copy static delivery, and offload TLS with session caching and HTTP/2. Finally, measure with real load tests and tune buffers and timeouts rather than guessing.
- Higher requests per second on the same hardware
- Lower latency and CPU usage under load
- Fewer backend hits via caching
- Reduced bandwidth from compression
- Graceful behaviour under traffic spikes
AI Mentor Explanation
Optimizing Nginx is like preparing a fielding side for a high-scoring one-day match: you place one fielder per zone (a worker per core), drill quick returns so no ball is chased twice (keepalive reuse), and memorize the batter's favourite shots to pre-position (caching), so the team covers far more deliveries without extra players on the pitch.
Step-by-Step Explanation
Step 1
Match workers to CPU
Set worker_processes auto and raise worker_connections plus the OS ulimit for file descriptors.
Step 2
Reuse connections
Enable keepalive for clients and add an upstream keepalive pool to avoid repeated TCP and TLS handshakes.
Step 3
Cache aggressively
Configure proxy_cache or fastcgi_cache so repeat requests are served without hitting the backend.
Step 4
Compress and offload static
Enable gzip or brotli, use sendfile and tcp_nopush, and serve static files directly.
Step 5
Tune TLS and HTTP/2
Enable ssl_session_cache, OCSP stapling and HTTP/2 to cut per-connection overhead.
Step 6
Load test and iterate
Benchmark with tools like wrk, then adjust buffers, timeouts and keepalive values from real data.
What Interviewer Expects
- Worker/connection and file-descriptor tuning as the foundation
- Understanding of keepalive for client and upstream connections
- Use of proxy/FastCGI caching to reduce backend load
- Static-file, compression and sendfile optimizations
- TLS and HTTP/2 tuning awareness
- A measure-then-tune mindset rather than blind config changes
Common Mistakes
- Raising worker_connections without raising the OS file-descriptor limit
- Forgetting upstream keepalive so every proxied request reopens a connection
- Enabling gzip on already-compressed assets like images
- Never load testing and guessing at buffer and timeout values
- Caching dynamic, user-specific responses incorrectly
Best Answer (HR Friendly)
“To make Nginx handle heavy traffic, you tune it to use every CPU core fully, reuse network connections instead of constantly reopening them, and cache and compress content so it does less repeat work. Then you load test and adjust the settings based on real numbers rather than guessing.”
Code Example
worker_processes auto;
worker_rlimit_nofile 100000;
events {
worker_connections 4096;
multi_accept on;
}
http {
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
gzip on;
proxy_cache_path /var/cache/nginx keys_zone=app:100m inactive=60m;
upstream backend {
server 127.0.0.1:8080;
keepalive 64;
}
server {
location / {
proxy_cache app;
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
}Follow-up Questions
- How does upstream keepalive differ from client keepalive?
- When should you use proxy_cache versus a dedicated CDN?
- How do you size worker_connections relative to file descriptors?
- What metrics tell you Nginx is the bottleneck versus the backend?
- How does HTTP/2 change connection tuning?
MCQ Practice
1. What is the recommended value for worker_processes on most servers?
Setting worker_processes to auto creates one worker per CPU core, maximizing parallelism without oversubscription.
2. Which directive avoids repeated TCP handshakes to backend servers?
An upstream keepalive pool reuses established backend connections instead of opening a new one per request.
3. Enabling gzip is least useful for which content?
JPEG, PNG and video are already compressed, so gzip wastes CPU with little size reduction.
Flash Cards
worker_processes auto? — Spawns one worker per CPU core for full parallelism.
Why upstream keepalive? — Reuses backend connections, avoiding repeated TCP/TLS handshakes.
Role of proxy_cache? — Serves repeat requests from cache, cutting backend load and latency.
sendfile + tcp_nopush? — Zero-copy static file delivery in full-sized packets.