keepalive versus worker_connections: trade‑off for short‑lived connection latency in nginx
0 reputation · 28 May 2021, 03:41 UTC
The goal is to lower request latency for short‑lived, bursty traffic in nginx without exceeding system file descriptor limits or causing excessive memory use.
Increasing worker_connections lets each worker handle more simultaneous sockets, but raises memory pressure and may hit FD limits. Enabling keepalive reuses existing TCP connections, cutting handshake overhead, yet its effectiveness depends on keepalive_timeout and upstream timeout settings, and too high a keepalive value can retain idle connections unnecessarily.
Should I prioritize raising worker_connections or configuring keepalive to achieve the lowest latency? What keepalive value balances connection reuse with FD availability given a typical worker_processes auto setting? How does the interaction between keepalive_timeout and upstream server timeouts affect the decision?