Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Performance Engineering

Performance engineering is the discipline of designing, building, measuring, and optimizing software systems to meet specific performance requirements. It sits at the intersection of systems engineering, applied mathematics, and practical software development—and it is one of the most interview-relevant skills for backend, infrastructure, and SRE roles.

Why It Matters

  • Production impact: A 100ms increase in page load time can reduce conversion rates by 7% (Google). Performance directly affects revenue, user retention, and infrastructure cost.
  • Interview relevance: System design interviews frequently ask you to estimate latency, reason about throughput, and discuss how you would diagnose slow services.
  • Cost optimization: A 2× throughput improvement at constant latency halves your infrastructure bill.

Core Dimensions

DimensionDefinitionTypical UnitExample Target
LatencyTime to complete a single operationms, μsp99 < 200ms
ThroughputOperations completed per unit timereq/s, MB/s10,000 QPS
Resource UtilizationFraction of available capacity in use%CPU < 70%
AvailabilityFraction of time the system serves requests% (nines)99.99%
EfficiencyWork done per unit of resourcereq/CPU-secCost per request

These dimensions trade off against each other. Pushing throughput higher often increases tail latency. Maximizing utilization reduces headroom for spikes.

Percentiles: Why Averages Lie

Averages hide tail behavior. Consider a service where 99 requests complete in 10ms and 1 request takes 10,000ms:

  • Mean: 109.9ms — looks fine
  • p50 (median): 10ms — half the requests are fast
  • p99: 10,000ms — 1% of users see catastrophic latency
  • p99.9: 10,000ms — 0.1% still affected
PercentileNameMeaning
p50Median50% of requests are faster than this
p9090th10% of requests are slower than this
p9595thCommon SLO target
p9999thCritical for user experience
p99.9Three-ninesInfrastructure-level SLA target

Google’s SRE team famously tracks p99 latency at the 99th percentile of 5-minute windows (not per-request) to catch sustained degradation.

Systematic Approach to Performance Problems

flowchart TD
    A[Define the Problem] --> B[Measure Baseline]
    B --> C[Identify Bottleneck]
    C --> D[Form Hypothesis]
    D --> E[Apply Fix]
    E --> F[Measure Again]
    F --> G{Improved?}
    G -->|Yes| H[Document & Ship]
    G -->|No| C
  1. Define: What exactly is slow? Use specific SLOs (“p99 > 500ms”), not vague complaints.
  2. Measure: Establish a reproducible baseline with proper tooling (see benchmarking).
  3. Identify: Use the USE Method (Utilization, Saturation, Errors) per resource, or RED Method (Rate, Errors, Duration) per service.
  4. Hypothesize: Generate a ranked list of likely causes. Profile, don’t guess.
  5. Fix & Verify: Make one change at a time. Re-measure to confirm.

Topics in This Section

TopicDescription
CPU ProfilingFlame graphs, perf, language-specific tools
Memory ProfilingLeak detection, GC tuning, cache analysis
BenchmarkingMicrobenchmarks, load testing, statistical rigor
Optimization TechniquesAmdahl’s Law, caching, batching, concurrency
Latency AnalysisTail latency, budgets, histograms, coordinated omission

References

Interview Questions

  1. What’s the difference between latency and throughput? Can you have high throughput and high latency?
  2. Why is p99 more important than mean latency for user-facing systems?
  3. How would you diagnose a sudden latency spike in a microservice?
  4. What is the USE Method, and when would you apply it?
  5. Explain how a 1% regression in p99 could be more concerning than a 10% regression in mean latency.
  6. How do you set an SLO? What factors determine whether you target p95 or p99?
  7. What tools would you use to profile a CPU-bound Go service in production?