Performance Profiling And Load Testing Orientation

Performance work starts with measurement. Profiling identifies where time and memory are spent; load testing shows how a system behaves under representative concurrency and traffic shape.

Measure A Representative Workload

  • Measure latency distributions, errors, throughput, and saturation.
  • Profile representative slow paths.
  • Test staging or controlled environments safely.

Compare Before And After

  • Define baseline workload.
  • Run controlled test.
  • Change one bottleneck and compare.

Avoid Misleading Tests

  • Average latency hides tail problems.
  • Unrealistic load creates misleading results.
  • Load tests can damage shared environments.

Load Test Report

workload: product list and product detail mix
measure: requests/sec, p50, p95, p99 latency, error rate
observe: CPU, memory, FPM queue, database load, cache hit rate

Profiling and load testing are useful when one measured bottleneck is improved without guessing. Run controlled tests against an approved environment; an unrealistic or unsafe load test can create misleading results or damage shared systems.

Workload Models

Closed models keep a fixed number of virtual users cycling through work. Open models generate arrivals at a target rate. Choose the model that resembles demand; a closed test can hide overload because slower responses reduce request generation.

Percentiles And Saturation

Report p50, p95, and p99 latency with throughput and error rates. Correlate those results with CPU, memory, PHP-FPM active and queued workers, database connections and slow queries, cache hit rate, queue depth, and external-service latency.

Frontend And Backend Are Different

HTTP load generators measure backend capacity. Browser tools measure page loading, JavaScript, rendering, and interaction. Use both when the user experience depends on both, but do not interpret a Lighthouse run as a server capacity test.

Capacity Findings

A useful report states the tested release, environment, data volume, cache state, workload, generator capacity, bottleneck, safe operating range, and next experiment. One peak number without error and latency context is not a capacity plan.

Practice

Practice: Plan A Product API Load Test

Plan a controlled load test for product-list and product-detail API routes. Define the workload, signals, and safety limits before running it.

Requirements

  • Measure latency distributions, errors, throughput, and saturation.
  • Profile representative slow paths.
  • Test staging or controlled environments safely.
  • Define baseline workload.
  • Run controlled test.
  • Change one bottleneck and compare.
Show solution

Choose a representative mix of list and detail requests, expected concurrency, duration, and an approved target environment. Measure throughput, errors, p50, p95, and p99 latency alongside CPU, memory, FPM queueing, database load, and cache behaviour.

Set stop conditions so the test cannot overwhelm shared systems. Profile a slow path, change one bottleneck, and compare the same workload before claiming an improvement.

Practice: Interpret Load-Test Percentiles

A test has a low average but high p99 latency and a growing PHP-FPM queue. Explain the result.

Your answer must identify the intended behavior, the important failure case, and the evidence that proves the result.

Show solution

A minority of users experience severe delay while worker capacity is saturated. Inspect slow dependencies and queueing, reduce or optimize work, tune only from measured worker memory and downstream capacity, then repeat the same workload.

Verify the real response, deployment, or workload rather than relying only on configuration text.

Practice: Choose Open Or Closed Load

Choose a model for a fixed internal user population and for unpredictable public webhook arrivals.

Your answer must identify the intended behavior, the important failure case, and the evidence that proves the result.

Show solution

A closed model can represent the fixed interactive population with think time. An open arrival-rate model better represents webhooks that continue arriving even when processing slows.

Verify the real response, deployment, or workload rather than relying only on configuration text.