NGINX Capacity Calculator
Derive NGINX connection capacity from worker processes and worker_connections, and the proxy buffer memory it commits.
Inputs
Maximum Client Connections
65,536
Maximum Proxied Requests
32,768
Concurrent In-Flight Requests
750
Proxied Connection Utilisation
2.29%
Worst-Case Proxy Buffer Memory
2 GiB
File Descriptors Needed per Worker
16,416
Step by step
Values used
worker_processes = 8 workers; worker_connections = 8,192 connections; Requests per second = 30,000 rps; Average request duration = 25 ms; proxy_buffers per connection = 32 KB
NGINX Capacity
max connections = worker_processes × worker_connections; when proxying, each request consumes two slots (client and upstream), so proxied capacity is half that.
Maximum Client Connections
= 65,536
Maximum Proxied Requests
= 32,768
Concurrent In-Flight Requests
= 750
Proxied Connection Utilisation
= 2.29
Worst-Case Proxy Buffer Memory
= 2,147,483,648
File Descriptors Needed per Worker
= 16,416
How it works
Every connection slot in NGINX maps to a file descriptor, and a reverse-proxied request holds two — one facing the client and one facing the upstream. Little's law converts a request rate and duration into the number of slots actually occupied, which is usually a tiny fraction of the configured ceiling. Raising worker_connections without raising worker_rlimit_nofile is the classic NGINX misconfiguration, and the buffer memory column shows why a generous proxy_buffers setting can commit gigabytes of RAM.
Formula
NGINX Capacity
max connections = worker_processes × worker_connections; when proxying, each request consumes two slots (client and upstream), so proxied capacity is half that.
- proxiedConnections
- Half of max connections, because a proxied request holds two descriptors
- concurrentRequests
- Requests per second × duration, by Little's law
Frequently Asked Questions
How is NGINX Capacity calculated?
max connections = worker_processes × worker_connections; when proxying, each request consumes two slots (client and upstream), so proxied capacity is half that. Every connection slot in NGINX maps to a file descriptor, and a reverse-proxied request holds two — one facing the client and one facing the upstream. Little's law converts a request rate and duration into the number of slots actually occupied, which is usually a tiny fraction of the configured ceiling.
Why does NGINX Capacity matter?
Raising worker_connections without raising worker_rlimit_nofile is the classic NGINX misconfiguration, and the buffer memory column shows why a generous proxy_buffers setting can commit gigabytes of RAM.
What values do I need to enter?
This calculator takes 5 inputs: worker_processes, worker_connections, Requests per second, Average request duration, proxy_buffers per connection. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
You might also need
- HAProxy Capacity CalculatorCommonly used together
- Reverse Proxy Throughput CalculatorCommonly used together
- Connection Pool CalculatorCommonly used together
- WebSocket Capacity CalculatorAlso in Load Balancing & ADC
- Least Connections CalculatorAlso in Load Balancing & ADC
- Session Persistence CalculatorAlso in Load Balancing & ADC