Performance Tuning, Logging & Troubleshooting (Failed Request Tracing)

Web Servers Fundamentals Chapter 9 named Dynamic/Static Content Compression and Output Caching briefly, comparatively. This chapter goes deep on both, on real logging configuration, and — finally — on Failed Request Tracing, the tool Chapters 2, 5, and 8 each pointed forward to as the definitive way to turn a confusing failure into an actual root cause.

Static vs. Dynamic Compression, and IIS's Own CPU Throttle

Static compression compresses a static file once and caches the compressed copy on disk, serving that cached copy for every subsequent request — genuinely cheap, since the CPU cost is paid exactly once no matter how many times the file is requested afterward. Dynamic compression compresses generated, per-request content fresh every single time, since the content itself is different on each request — a real, ongoing CPU cost that scales directly with request volume. IIS has a genuinely distinctive safeguard here that neither Apache nor Nginx has built in the same way: dynamicCompressionDisableCpuUsage automatically turns off dynamic compression once server CPU usage crosses that threshold, and dynamicCompressionEnableCpuUsage turns it back on once usage drops below the lower one — an adaptive mechanism that trades away some bandwidth savings under real load rather than letting compression itself become the thing that overloads the server.

Kernel-Mode Output Caching vs. User-Mode Caching

Web Servers Fundamentals' own comparative Output Caching mention didn't distinguish these two — but the difference is substantial. IIS's kernel-mode cache lives inside http.sys, the kernel driver that receives every incoming HTTP request before it ever reaches user-mode code at all. A cache hit there is served directly by the kernel driver itself — the IIS worker process (w3wp.exe) never even wakes up for that request, which is why kernel-mode cache hits are dramatically cheaper than any user-mode alternative. The user-mode output cache (system.webServer/caching) is the fallback for content that can't be kernel-cached at all — it still requires the worker process to run, just skipping the actual content-generation step on a cache hit.

Logging: W3C Extended Format and Rollover

The W3C Extended Log File Format is IIS's own default, configurable field-by-field — time-taken (request duration in milliseconds) is particularly useful paired with Failed Request Tracing below, since a slow-but-successful request often needs a different diagnosis than an outright failure. Log files land under %SystemDrive%\inetpub\logs\LogFiles by default, one subfolder per site, rolling over on the configured period (Hourly/Daily/Weekly/Monthly) or once a file reaches truncateSize. For a multi-server web farm, Centralized Binary Logging is a real alternative worth knowing about: a single shared binary log file across every server rather than separate per-server text logs, avoiding the need to reconcile logs from several machines by hand — a genuinely different tradeoff from either Apache's or Nginx's own typically per-server text log files.

Failed Request Tracing: The Forward-Referenced Payoff

This is the tool Chapter 2 named as the way to find out why a pool kept crash-looping into Rapid-Fail Protection, that Chapter 5 named as scoped per application, and that Chapter 8 named as the way to turn "the request got a 401/403" into an actual cause. failureDefinitions tells IIS exactly which requests are worth capturing — here, a specific set of status codes or any request taking over 10 seconds — rather than tracing every single request, which would be prohibitively expensive and fill disk space fast. Once a matching request occurs, IIS writes a detailed XML file recording every pipeline event and module notification the request passed through, each with its own precise timestamp — the exact module that returned 401, the exact point a request crossed the 10-second threshold, or the exact point in the pipeline where a worker process crash actually occurred. Opened in a browser (the generated XML ships with its own XSL stylesheet), this turns a bare status code or a Rapid-Fail Protection 503 into a genuine, attributable root cause — module by module, event by event.

Hands-On Exercises