Apache Keep-Alive Tuning: Reduce Latency by Reusing TCP Connections

The problem: every request pays a handshake cost

\n

When Keep-Alive is off, Apache closes the TCP connection after each HTTP response. The next request forces a full three-way handshake, adding round-trip latency especially on high-latency networks or mobile clients. On a busy server, this multiplies across thousands of requests.

\n\n

How Keep-Alive works

\n

Keep-Alive is an Apache directive that tells the server to leave the TCP connection open after a response. Subsequent requests can reuse the same connection, skipping the handshake. This is especially effective for static assets, API endpoints, or any workload with repeated calls to the same host.

\n\n

Default settings and what to watch

\n

Apache 2.4 ships with KeepAlive On enabled by default. The timeout defaults to KeepAliveTimeout 5, balancing reuse with resource retention. There's also MaxKeepAliveRequests, which limits how many requests can ride a single connection before Apache closes it (unlimited by default). Finally, MaxRequestWorkers must be set high enough to handle the extra connections that persistent connections create, otherwise you'll see workers exhausted under load.

\n

\n
• KeepAliveTimeout 5 – seconds to wait for the next request on an idle connection
\n
• MaxKeepAliveRequests unlimited – requests per connection before closure
\n
• MaxRequestWorkers – maximum simultaneous child processes; tune to expected concurrent persistent connections
\n

\n\n

Worked example: measuring the gain

\n

Use wrk or ab to compare latency with Keep-Alive on and off. Run the command on any machine that can reach your Apache host:

\n

# Where: a client machine with network access to Apache\n# Permissions: unprivileged user; wrk does not require root\n# Placeholder: replace http://localhost:8080/api/status with your target URL\nwrk -t2 -c100 -d30s http://localhost:8080/api/status

\n

While the test runs, monitor server state (requires mod_status):

\n

serverctl status | grep "Busy workers"\nserverctl status | grep "Idle workers"

\n

Expected checks: Compare average and 95th-percentile latency between runs; observe whether "Idle workers" remain stable or "Busy workers" decrease faster when Keep-Alive is off.

\n

Relevant risks: Without tuning MaxRequestWorkers and KeepAliveTimeout, high concurrency with persistent connections can deplete available workers, increasing request queueing latency. Start with conservative settings and adjust based on observed metrics.

\n\n

Trade-off: resource retention vs handshake savings

\n

Keeping connections open consumes file descriptors and worker slots. If many clients open persistent connections and never reuse them, or if the timeout is too long, Apache can accumulate idle-but-held connections, driving up "Busy workers" and reducing capacity for new requests. Setting MaxKeepAliveRequests to a finite number (e.g., 100) caps connection lifespan, and matching KeepAliveTimeout to your typical round-trip time (often 2–4 seconds on local networks) prevents excess retention.

\n\n

Actionable checklist

\n

\n
1. Ensure KeepAlive On is present in httpd.conf (or default in Apache 2.4+)
\n
2. Set KeepAliveTimeout to your network's round-trip time (start with 2–5)
\n
3. Assign a finite MaxKeepAliveRequests if you see connection bloat
\n
4. Adjust MaxRequestWorkers to accommodate expected concurrent persistent connections
\n
5. Re-benchmark with your real workload and verify latency improvement
\n