Skip to content

What is performance testing?

Performance testing is the practice of deliberately applying load to a system and observing how it behaves — how fast it responds, how much traffic it can sustain, and where it breaks. The goal is not to break your system on purpose; the goal is to discover the system’s limits under controlled conditions before real users discover them under uncontrolled ones.

A well-designed performance test answers concrete, measurable questions:

  • Capacity: How many concurrent users can my system handle before response times exceed my SLO?
  • Latency: Is the p95 latency for the checkout API under 500 ms when 200 users are active?
  • Stability: Does the system stay healthy after eight hours of sustained load (soak test)?
  • Recovery: Does latency return to baseline after a sudden traffic spike (spike test)?
  • Regression: Did the last deployment change how fast the system responds under the same load?

Each of these maps to a specific test type. Foundations gives you the vocabulary to understand the results; Test types gives you the playbook for each scenario.

In MaxoPerf a performance test follows a consistent lifecycle:

  1. Test definition — You create a test with a script (Taurus YAML, JMeter JMX, or k6 JavaScript) and a load profile (virtual users, duration, ramp-up, locations).
  2. Run initiation — You click Run or trigger via the API. MaxoPerf creates a run record in queued status.
  3. Allocation — MaxoPerf allocates runners — one or more cloud VMs in the location(s) you chose (managed cloud locations or your own private locations) — and the status moves to allocatingstarting.
  4. Execution — The engine (Taurus/JMeter/k6) runs on the allocated runners and generates load against your target. Status is running. The run-detail Overview tab streams live throughput and latency charts.
  5. Completion — Load stops, runners drain, status becomes finished. All result data — latency percentiles, throughput, error breakdown, logs — is preserved immutably.

This five-step lifecycle is covered in depth in Tests and runs.

Performance testing is most valuable when it is continuous, not a one-time pre-launch activity.

MomentWhy
After each significant backend changeCatch regressions before they reach users.
Before a major launch or promotionConfirm the system handles expected peak load.
After an infrastructure change (new DB, caching layer, CDN)Verify the change had the intended effect on latency and throughput.
On a scheduled cadence (soak test)Detect slow memory leaks and resource exhaustion before they become incidents.
After an incidentReproduce the load pattern that caused the incident to confirm the fix holds.

MaxoPerf schedules let you run a test on a cron schedule so performance regressions surface in your inbox, not in your incident queue. See the Scheduled regression test recipe for the setup.

The two terms are often used interchangeably. In this library:

  • Performance testing is the broad discipline — any test that measures system behavior under some form of stress or load.
  • Load testing is the most common form — sustaining a representative level of concurrent users over time to measure steady-state behavior.

Other forms (stress, spike, soak, breakpoint) are specializations. All are covered in Test types.

DoDon’t
Define a measurable question before you run a test.Run load tests without knowing what “pass” looks like.
Use managed cloud locations for external traffic simulation or private locations for internal/behind-firewall targets.Aim at production without explicit authorization and a plan for blast radius.
Compare every run to a baseline.Treat a single run result as absolute truth without a reference point.
Start with a smoke test (1-5 VUs) to confirm the test setup is correct before ramping up.Ramp immediately to full load and wonder why results are noisy.