Architecture Models

Web Servers Fundamentals

Chapter 2 · Architecture Models

Chapter 1 established what a web server does in the abstract: accept connections, parse requests, send back responses. This chapter is about how each of the three servers actually handles doing that many times at once — the specific architectural choice behind each one, and why it matters once real traffic shows up.

Apache's Multi-Processing Modules (MPMs)

Apache handles concurrency through a pluggable Multi-Processing Module, chosen at configuration time rather than fixed. Prefork is the oldest and simplest: one entire process handles one connection at a time, with a pool of processes spawned in advance — straightforward and very stable, but memory-heavy under high concurrency since every process carries its own full memory footprint. Worker is a hybrid: multiple processes, each running multiple threads, so a single process can handle several connections concurrently, using less memory overall than Prefork. Event, the modern default, refines Worker further by handling idle keep-alive connections without tying up a full worker thread for each one — closing much of the gap with Nginx's own model.

Nginx's Event-Driven Architecture

Nginx was built specifically to solve what's often called the "C10K problem" — handling ten thousand or more simultaneous connections without the per-connection overhead of Apache's original process/thread model. It runs a small, fixed number of worker processes, each running a single-threaded event loop that uses non-blocking I/O to juggle many connections at once without dedicating a thread or process to each one. This is why Nginx's own memory and CPU usage tends to stay flatter as connection counts climb, compared to a process- or thread-per-connection model.

IIS's Application Pool Model

IIS isolates applications into Application Pools, each backed by its own worker process (w3wp.exe), so one misbehaving application can't easily crash or starve another running on the same server. Each pool's worker process integrates directly with the .NET runtime's own threading model for handling concurrent requests, and IIS can automatically recycle a pool's worker process on a schedule or after memory thresholds, trading a small amount of overhead for resilience against slow memory leaks in long-running applications.

	Apache (Event MPM)	Nginx	IIS
Concurrency model	Processes + threads, with idle connections offloaded	Event-driven, non-blocking, few worker processes	Worker process per application pool, .NET threading inside
Memory under high load	Moderate — improved a lot over Prefork	Low and flat — Nginx's own signature strength	Depends on the application; pools isolate the blast radius
Isolation	Per-process, module-dependent	Per-worker, not per-application by default	Strong — one pool crashing doesn't take down another
Best suited for	Flexible, module-heavy setups	Very high concurrency, static + reverse-proxy workloads	Windows/.NET application hosting

Why this matters beyond just "which is faster"

These architecture choices directly affect how each server behaves under real, concurrent traffic — not just raw single-request speed. Per Chapter 1's own static/dynamic distinction, a server juggling thousands of connections that are mostly waiting on a slow backend behaves very differently depending on whether idle connections cost a full thread (Apache's older MPMs) or almost nothing (Nginx, Apache's own Event MPM).

"Apache is just outdated" is an oversimplification

It's tempting to treat this chapter's comparison as "Nginx's architecture is simply better." In practice, Apache's modern Event MPM closes most of the concurrency gap that made Nginx famous in the first place. The real, lasting differentiator between these servers isn't raw concurrency architecture anymore — it's the configuration philosophy each one is built around, which Chapter 3 covers directly, and that difference is a genuine trade-off, not a strict improvement in either direction.

Hands-On Exercises

Exercise 1

Explain, in your own words, why Apache's Prefork MPM uses more memory under high concurrency than Nginx's event-driven model, even when both are ultimately serving the same static file to many clients at once.

📄 View solution

Exercise 2

A Windows server hosts two separate ASP.NET applications for two different clients. One client's application has a memory leak. Explain, using IIS's Application Pool model, why the other client's application is likely unaffected — and what recycling would do about the leak.

📄 View solution

Exercise 3

A colleague claims "Apache is obsolete now that Nginx exists." Using this chapter's own warning box, write a short, accurate response explaining what's true and what's an oversimplification in that claim.

📄 View solution

Chapter 2 Quick Reference

Apache — pluggable MPMs: Prefork (process-per-connection), Worker (processes + threads), Event (modern default, offloads idle connections)
Nginx — a small number of worker processes, each an event-driven, non-blocking loop handling many connections at once
IIS — one worker process (w3wp.exe) per Application Pool, isolated from other pools, with scheduled recycling
Apache's modern Event MPM has closed most of the old Apache-vs-Nginx concurrency gap — the real differentiator now is configuration philosophy (Chapter 3)