Performance Tuning, Logging & Troubleshooting

Web Servers Fundamentals Chapter 9 named KeepAlive/KeepAliveTimeout and mod_cache without real values or directives, and closed with a serious, correct warning: caching personalized content by URL alone can leak one user's data to another. This chapter goes deep on all three — KeepAlive tuning tied directly back to Chapter 2's own capacity math, the actual mod_cache_disk mechanism that prevents exactly the leak Fundamentals warned about, and the practical logging and troubleshooting tools that round out this course before its capstone.

KeepAlive Tuning — Tied to Chapter 2's Own Capacity Math

KeepAliveTimeout isn't a free setting to raise generously — it directly connects to Chapter 2's own MaxRequestWorkers capacity math. Under Prefork, a connection sitting idle during its keep-alive window still occupies an entire process; under Worker, it still occupies an entire thread — either way, it counts against the same real ceiling a genuinely busy request would, for as long as the timeout keeps it open. A KeepAliveTimeout set too high (a common instinct: "longer must be better for reuse") can quietly starve real capacity with connections doing nothing at all. This is exactly the problem Chapter 2's own Event MPM solves — its AsyncRequestWorkerFactor handling of idle keep-alive connections is precisely what makes a longer KeepAliveTimeout far cheaper under Event than under Prefork or Worker. A short window (5–15 seconds is typical) is the usual safe default outside of Event.

mod_cache_disk In Depth — Actually Preventing Fundamentals' Own Warning

CacheRoot sets where cached responses are stored on disk; CacheEnable disk /static/ turns caching on for that path specifically, rather than site-wide; CacheDirLevels/CacheDirLength control how cache files are spread across subdirectories to avoid one directory holding an unmanageable number of files. The part that actually matters for Fundamentals' own warning is what mod_cache does by default: it respects Cache-Control headers from the backend, refusing to cache anything marked private or no-store. For content that legitimately does vary per user but is still worth caching, the backend's own Vary response header — e.g. Vary: Cookie — tells mod_cache to key its stored copies separately per distinct value of that header, rather than serving one shared cached copy to every visitor of the same URL.

Custom Log Formats

Fundamentals mentioned LogFormat exists without ever showing it; the standard combined format above is worth being able to read directly: %h is the client IP, %l is the (almost always unused) identd field, %u the authenticated username if any, %t the timestamp, %r the full request line, %>s the final HTTP status code, %b the response size in bytes, and the two %{...}i tokens pull specific request headers directly — Referer and User-Agent here, but any header name works the same way.

Troubleshooting: configtest Before Every Reload

This validates the entire configuration's syntax without actually reloading or restarting anything — critical to run before every real reload, since applying a broken config live can take the whole site down with it. Two of the most common real error-log patterns worth recognizing on sight: AH00526: Syntax error on line N (a straightforward config typo, pointing at the exact line), and (98)Address already in use: AH00072: make_sock: could not bind to address (something else — often a previous Apache process that didn't fully stop — is already holding the port). A 403 logged as AH01630: client denied by server configuration traces directly back to Chapter 8's own Require/RequireAll rules rejecting the request.

Hands-On Exercises