Challenge 3: The Diagnostic Order for a Slow Site — Solution Walkthrough

The order, and what each check reveals:

  1. Check the error log first (Web Servers Fundamentals Chapter 8).
     This is the fastest way to catch an outright misconfiguration or
     failure that's already announcing itself directly, before
     spending time on deeper investigation.

  2. Check stub_status. This reveals whether Nginx itself currently
     shows a high number of active connections or requests
     waiting/reading/writing — telling you whether the bottleneck is
     inside Nginx's own handling of connections, or whether Nginx
     looks idle and the real slowdown must be happening somewhere
     else (most likely the backend).

  3. Check the X-Cache-Status header (Chapter 7). This rules caching
     in or out as a factor — a response showing MISS repeatedly when
     it should be cacheable points at a cache-key or cache-validity
     misconfiguration; consistent HIT responses that are still slow
     point away from caching as the cause entirely.

  4. Check worker_connections and the OS file-descriptor limit
     (Chapter 2). This rules out a silent connection ceiling being
     hit — a symptom that can look like general slowness or dropped
     connections but is actually a fixed capacity limit being reached,
     not a performance-tuning problem in the traditional sense.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the diagnostic checklist from this chapter
is understood as an actual ordered troubleshooting sequence — each
step narrowing down where the problem lives — rather than four
disconnected facts to recall in any order.