Performance Testing Services

The useful output of performance testing is a statement of where the system stops behaving and what stops it: the concurrency at which response time leaves its acceptable band, the resource that saturates first, and the evidence tying one to the other. That is actionable — it tells you whether to tune a query, add a cache, resize an instance group or change an architecture. A green run with no bottleneck identified tells you only that you did not push hard enough.

Percentiles matter more than averages, and it is worth being blunt about why. A mean response time hides the tail where your unhappiest users live; a p95 and p99 describe the experience that generates the support tickets. We report distributions, and we report the load level at which each one degrades.

A load test measures behaviour at the traffic you expect, and is the right instrument for capacity planning. A stress test deliberately pushes past that to find the breaking point and, more importantly, to see whether the system degrades gracefully or falls over — a service that sheds load cleanly is in a different class from one that cascades. A soak test holds moderate load for hours to surface what only appears with time: memory leaks, connection-pool exhaustion, log volumes filling a disk. A spike test models the sudden arrival — a campaign, a market open — where the problem is the rate of change rather than the absolute number.

Most systems need more than one, and the order matters: establish expected-load behaviour first, because a stress result is hard to interpret without knowing what normal looks like.