3.4.2. Baselining and Performance Metrics
💡 First Principle: You cannot identify abnormal performance without knowing what normal looks like. A baseline is a documented snapshot of system performance during known-good, representative operation. Everything that happens afterward is measured against it.
Baselining Process
- Choose representative conditions: Capture metrics during typical workload (not during off-hours or a holiday when load is artificially low)
- Measure all key resources: CPU, memory, disk (IOPS, latency, throughput), and network (utilization, errors)
- Document and store: The baseline becomes the comparison point for troubleshooting and capacity planning
- Repeat periodically: Performance profiles change as workloads grow; update baselines quarterly or after significant configuration changes
Key Performance Metrics
| Metric | What It Measures | Warning Signs |
|---|---|---|
| CPU utilization | Processing load | Sustained >80% suggests a bottleneck |
| Memory utilization | RAM consumption | High paging/swap activity indicates memory pressure |
| Disk IOPS | Disk operation rate | Saturation causes queue depth growth and latency spikes |
| Disk throughput | Data transfer rate (MB/s) | Near-capacity throughput indicates bottleneck |
| Disk latency | Time per I/O operation | HDD: >20ms is concerning. SSD: normal is well under 1ms (SATA ~50–100 µs, NVMe ~10–20 µs), so >1ms warrants investigation and >5ms is an alert |
| Network utilization | Bandwidth consumption | Sustained >70–80% on a link suggests saturation |
| Capacity vs. utilization | How full resources are | Proactive metric for planning before saturation |
Baselining in the Context of Documentation
A baseline isn't just a number—it's a documented state with context: the date, the workload, and any relevant conditions. When performance degrades months later, having a well-documented baseline tells you exactly how much performance has changed and when it began.
⚠️ Exam Trap: A server showing high CPU utilization is not automatically experiencing a CPU bottleneck. High CPU during a burst is normal; sustained high CPU that doesn't drop is a bottleneck. Similarly, some workloads (encryption, video encoding) are CPU-intensive by design.
Reflection Question: After a routine firmware update, users report the server feels "slower." You have no baseline data. Why does this make the problem significantly harder to diagnose?
