Nginx · The edge of your stack

How do you tune Nginx for production performance?

HardperformancetuningthroughputUpdated Oct 2026

Short answer

Measure first, then tune workers, file descriptors, keepalive, sendfile, caching and upstream reuse. Most latency wins come from reducing connection setup, TLS handshakes and backend work rather than micro-optimizing directives.

Tuning without measurement usually moves the bottleneck. Use request time versus upstream time to separate edge latency from backend latency, and watch CPU, memory, file descriptors and network at the same time.

nginx

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    use epoll;
    worker_connections 8192;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout 65;
    keepalive_requests 1000;

    open_file_cache max=10000 inactive=60s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
}

Where the gains usually are

Reuse upstream connections with keepalive instead of connecting per request
Enable TLS session reuse and HTTP/2 or HTTP/3 where appropriate
Cache static and cacheable API responses close to users
Serve static files from Nginx or a CDN, not from the application
Avoid broad regex locations on hot paths and keep configs small
Raise file descriptor limits and size workers for the machine
Measure p95 and p99, not only averages, and compare before and after

multi_accept and accept_mutex have trade-offs under high connection churn. reuseport can distribute accepts across workers, but test it with your kernel and traffic pattern rather than assuming it helps.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

1How do you know whether latency is in Nginx or the backend?
2Why does upstream keepalive matter more than many micro-optimizations?
3What are the trade-offs of multi_accept?
4How would you tune for TLS-heavy traffic?

Say it in the interview

I measure first and separate Nginx time from upstream time using the access log. Then I tune the big levers: worker count, file descriptor limits, upstream keepalive, TLS session reuse, caching and serving static files at the edge. I compare p95 and p99 before and after. I avoid copying tuning snippets blindly because multi_accept, reuseport and buffer sizes all have trade-offs that depend on traffic shape.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Nginx mock interview and get scored feedback on depth, clarity and confidence.

Start a free Nginx interview Browse all questions

Where the gains usually are

Follow-ups you should expect

Related questions

Now say it out loud.