SRE Performance Testing and Load Management

Question 1

What is the difference between a 'load test' and a 'stress test,' and when should each be used?

Accepted Answer

A load test validates performance under expected production traffic levels to verify SLOs are met; a stress test pushes beyond expected levels to find breaking points and understand failure modes

Answer

Load tests confirm that the system handles expected traffic volumes while meeting SLOs. Stress tests find capacity limits and failure behaviors by pushing beyond expected volumes — revealing what breaks first and how the system fails.

Question 2

What is 'throughput' vs. 'latency' in performance testing, and what is their typical trade-off relationship?

Accepted Answer

Throughput is the number of requests processed per second; latency is the time to process a single request. At low load, both can be optimized simultaneously, but at high load, higher throughput often comes with increased latency as queuing occurs

Answer

At low utilization, adding more requests doesn't significantly increase individual request latency. As utilization approaches capacity, queueing theory (Little's Law) predicts latency increases sharply — this is the hockey-stick latency curve observed in most systems.

Question 3

What is a 'p99 latency' measurement, and why do SREs prefer it over average (mean) latency for SLO monitoring?

Accepted Answer

p99 is the 99th percentile latency — 99% of requests complete faster than this value; it captures the experience of the worst-served 1% of users, which average latency hides by diluting outliers in the mean

Answer

Percentile latency (p95, p99, p999) captures tail latency experienced by real users. An average latency of 50ms can hide that 1% of users experience 5-second responses — p99 makes this visible and actionable.

Question 4

What is 'autoscaling,' and what metric is MOST appropriate to trigger autoscaling for a web API service?

Accepted Answer

Autoscaling adjusts the number of running instances based on demand; for a web API, scaling based on requests per second (RPS) or concurrent connections is more appropriate than CPU utilization alone, as some APIs are I/O-bound rather than CPU-bound

Answer

CPU-only autoscaling fails for I/O-bound services where CPU stays low even under heavy load because threads are waiting on database or network I/O. Request rate or concurrent connection metrics better represent actual service demand.

Question 5

What is the 'golden signals' framework and which four metrics does it include?

Accepted Answer

Latency, traffic (throughput), errors, and saturation — the four signals that best describe the health of any service from a user and capacity perspective

Answer

Google's four golden signals (from the SRE book) are the minimum set of metrics needed to understand service health: latency (how fast), traffic (how much load), errors (how much is failing), and saturation (how full/close to limit).

(SRE) Site Reliability Engineering Foundation Certification Practice Test

(SRE) Site Reliability Engineering Foundation Certification Practice Test

SRE Performance Testing and Load Management