Challenge 1: A 300-Second KeepAliveTimeout on Prefork With
MaxRequestWorkers 100 — Solution Walkthrough

Why this reduces real usable capacity:

Under Prefork, each connection -- busy or idle -- occupies one entire
process, and MaxRequestWorkers 100 is a hard ceiling on how many of
those processes can exist at once. A KeepAliveTimeout of 300 seconds
means that once a client finishes a request, the process handling it
stays reserved for that same client for up to five full minutes
afterward, doing nothing, just in case that client sends another
request. Every one of those idle-but-reserved processes counts
directly against the same MaxRequestWorkers=100 ceiling a genuinely
busy request would use.

Under real, bursty traffic, this means a large share of the
server's 100-process capacity can end up tied up holding idle
connections open rather than being available for new incoming
requests -- a burst of new visitors can get refused or queued not
because the server is doing genuinely heavy work, but because
processes are sitting idle, reserved for clients who may not even
send another request within that five-minute window at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can apply Chapter 2's
MaxRequestWorkers ceiling to a KeepAlive scenario specifically --
recognizing that under Prefork, "idle" and "using zero capacity" are
not the same thing, and that a generous-sounding timeout has a real,
quantifiable capacity cost.