Cloud load testing

Use case

Cloud load testing helps teams move beyond “I ran this on my laptop” and “we spun up a server for the test last quarter.” The goal is to make test capacity, configuration, and results repeatable enough that a release decision can depend on them — not just a passing reference in a postmortem.

The core problem is not the technology; it is the operational friction. Running a meaningful load test used to mean provisioning VMs, installing a test framework, managing SSH keys, aggregating results from multiple hosts, and then tearing everything down. That cost means most teams run load tests rarely, usually at the wrong time (just before a launch, under deadline pressure), and without consistent baselines to compare against.

Cloud load testing eliminates that friction. The platform provides the runner infrastructure. You provide the test and the threshold judgement.

How MaxoPerf supports it

Upload or author a test file (JMeter, Taurus, or Playwright), define a load profile, and select one or more managed runner regions. MaxoPerf provisions the infrastructure, executes the run, collects metrics, and presents results — all without you touching a VM.

Results include per-label latency percentiles, error rates, assertion results, runner health (CPU, memory, network), and request logs. Each run is stored with the test file, load profile, and region configuration, so the next team member who asks “how did we test this before the last outage?” gets a direct link, not a verbal summary.

If the target is behind a firewall or requires traffic from a specific network, you can add a private runner location alongside managed locations and compare results from both in the same run.

A concrete load profile

A media company runs a cloud load test before every major content release to validate their API and CDN edge layer:

• Target: content delivery API (GET /v2/articles/:id, GET /v2/feed, image metadata endpoint)
• Load profile: 3 managed regions (EU-West, US-East, AP-Southeast); ramp from 0 to 500 virtual users per region over 3 minutes; hold for 10 minutes; ramp down 2 minutes
• Thresholds: p95 < 150 ms for article fetch; CDN cache-hit rate > 95% (verified via assertion on X-Cache header); error rate < 0.2%
• Cadence: manual trigger 48 hours before major content launch; results reviewed in team standup before go/no-go decision

A recent release revealed that the new image-metadata endpoint had a missing CDN cache directive, causing p95 to reach 620 ms at 500 VU/region. The team added the cache header, reran the test, and confirmed p95 dropped to 85 ms before proceeding.

Practical rollout

1. Start with a stable API path — one request type, at 20 virtual users, in a single region. Confirm the script executes cleanly before adding complexity.
2. Run a baseline — execute at the concurrency that represents your expected peak before any application changes. Save it with a descriptive tag. This is your comparison point for every future run.
3. Increase load incrementally — move from 20 to 100 to 500 VUs only after each previous level shows stable, predictable results. Jumping directly to peak load on a new script produces confusing results.
4. Add regions — once single-region runs are stable, add a second and third region to understand geographic variance and CDN behaviour.
5. Save run context — add notes and tags to each run so future team members have context: “this was the pre-launch baseline for v3.2” is more useful than an unmarked timestamp.
6. Link results to decisions — in your release runbook or PR description, link directly to the MaxoPerf run that validated the build. This creates an auditable trail without extra documentation effort.