Challenge 1: Why Prefork Uses More Memory Than Nginx's Event Loop — Solution Walkthrough

What Prefork actually does:

Apache's Prefork MPM dedicates one entire operating-system process to
each active connection, drawn from a pool of processes spawned in
advance. Every one of those processes carries its own full memory
footprint — its own copy of Apache's loaded modules, its own stack,
its own everything — regardless of how little work that particular
connection is actually doing at any given moment.

What Nginx's event-driven model does instead:

Nginx runs a small, fixed number of worker processes, and each one
uses a single-threaded event loop with non-blocking I/O to juggle many
connections concurrently, inside that one process. Handling another
simultaneous connection doesn't require spinning up another whole
process — it just means the existing event loop is tracking one more
open connection, which costs comparatively little memory.

Why this shows up even for the "same" static file:

The file being served is identical either way — the difference is
entirely in how each server accounts for the *connections themselves*.
A thousand simultaneous clients requesting the same static file means
Prefork potentially needs something close to a thousand separate
processes (or clients queued waiting for one), each with its own
memory overhead, while Nginx's worker processes keep tracking all
thousand connections within the same small set of already-running
processes.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the "per-process overhead" vs.
"per-connection tracked inside a shared event loop" distinction from
this chapter's own architecture descriptions is understood as the
actual mechanical reason for the memory difference — not just as a
fact to memorize ("Nginx uses less memory") but as a consequence of
each server's own concurrency model.