Performance and Scalability Diagnosis
Use current primary guidance as a review baseline, then report only what the available evidence supports. Primary authority: official reference.
Workflow
- Define the affected journey, workload, percentile, units, environment, time window, and expected objective.
- Capture a reproducible baseline and separate client, network, queue, service, datastore, and dependency time.
- Form competing hypotheses for latency, saturation, allocation, locking, retries, fan-out, and load amplification.
- Use profiles, traces, query plans, metrics, and controlled load evidence to discriminate among hypotheses.
- Identify the first constrained resource and whether the limit is per request, per instance, or shared.
- Estimate headroom and scaling behavior with explicit assumptions; distinguish measurement from extrapolation.
- Recommend the smallest experiment or remediation capable of falsifying the diagnosis.
Boundaries
- Do not optimize from averages alone when tail behavior matters.
- Do not run load tests against shared or production systems without explicit authorization and safeguards.
- Do not claim scalability from a single local benchmark or an unrepresentative fixture.
Output
Return Symptom, Baseline, Hypotheses, Measurements, Causal diagnosis, Capacity estimate, and Next experiment.
1---2name: performance-scalability-diagnosis3description: Diagnose latency, throughput, resource, contention, and scalability problems using measured evidence and competing hypotheses. Use when a system is slow, unstable under load, or approaching a capacity boundary; do not silently optimize code.4license: MIT5---67# Performance and Scalability Diagnosis89Use current primary guidance as a review baseline, then report only what the available evidence supports. Primary authority: [official reference](https://sre.google/sre-book/monitoring-distributed-systems/).1011## Workflow12131. Define the affected journey, workload, percentile, units, environment, time window, and expected objective.142. Capture a reproducible baseline and separate client, network, queue, service, datastore, and dependency time.153. Form competing hypotheses for latency, saturation, allocation, locking, retries, fan-out, and load amplification.164. Use profiles, traces, query plans, metrics, and controlled load evidence to discriminate among hypotheses.175. Identify the first constrained resource and whether the limit is per request, per instance, or shared.186. Estimate headroom and scaling behavior with explicit assumptions; distinguish measurement from extrapolation.197. Recommend the smallest experiment or remediation capable of falsifying the diagnosis.2021## Boundaries2223- Do not optimize from averages alone when tail behavior matters.24- Do not run load tests against shared or production systems without explicit authorization and safeguards.25- Do not claim scalability from a single local benchmark or an unrepresentative fixture.2627## Output2829Return Symptom, Baseline, Hypotheses, Measurements, Causal diagnosis, Capacity estimate, and Next experiment.30