Performance Basics

Chapter 2 compared how each server handles many connections at once, and Chapter 6 mentioned caching in passing as one reason to reverse-proxy a single backend. This chapter covers three concrete performance techniques any of the three servers can apply, largely independent of the architecture debates earlier chapters focused on — and where each one can actually backfire if applied without thinking about what it's doing.

Keep-Alive Connections

Opening a new TCP connection (and, over HTTPS, repeating the TLS handshake from Chapter 7) for every single request is expensive. Keep-alive reuses one already-open connection for multiple requests instead, avoiding that repeated setup cost. Apache controls this with KeepAlive, KeepAliveTimeout, and MaxKeepAliveRequests; Nginx with keepalive_timeout and keepalive_requests; IIS through its own connection timeout settings in IIS Manager. All three enable keep-alive by default today — the main tuning question is how long to hold an idle connection open before closing it, trading a small amount of held-open resources against avoiding a future reconnection cost.

Compression

Compressing a response body (typically with gzip, or the newer and generally more efficient brotli) before sending it trades a small amount of server CPU time for meaningfully fewer bytes sent over the network — usually a clear win for text-based content like HTML, CSS, and JavaScript. Apache enables this via mod_deflate; Nginx via its gzip directive plus a gzip_types list naming which content types to compress; IIS through its Dynamic Content Compression and Static Content Compression settings in IIS Manager.

Caching

Caching happens at two different levels. Browser caching uses response headers like Cache-Control and Expires to tell the browser it can reuse a previously downloaded asset without re-requesting it at all for some period of time — set directly by the web server for static files. Server-side or proxy caching — Chapter 6's own caching mention, revisited here — stores a copy of a response on the server or reverse proxy itself, so a subsequent identical request can be answered from that stored copy without hitting the backend application again at all. Apache offers this via mod_cache; Nginx via proxy_cache; IIS via its own Output Caching feature.

Hands-On Exercises