Performance & Load Testing

Benchmark testing measures a system's performance against a known, standardized reference point — either an industry-standard benchmark or the system's own prior performance — to track whether it's getting faster, slower, or staying consistent over time. It's about comparison, not just raw measurement.

A bottleneck is the single component in a system that limits its overall performance under load — a slow database query, an under-provisioned server, a single-threaded piece of code — such that fixing anything else first won't improve throughput until the bottleneck itself is addressed.

Capacity testing determines the maximum load a system can handle — users, transactions, or data volume — while still meeting its defined performance requirements, establishing the ceiling a system can be scaled up to before it needs additional infrastructure.

Concurrent users is the number of users actively interacting with a system at the same moment — the key input variable in load and performance testing, since it's simultaneous demand, not total registered users, that actually determines whether a system holds up under real traffic.

Latency is the time delay between a request being sent and a response beginning to arrive — a component of overall response time, but distinct from it, since latency specifically measures the delay before data starts flowing, not the total time to receive everything.

Load testing measures how a system performs under an expected level of concurrent users or traffic, checking that response time, throughput, and error rate stay within acceptable limits at that load. Unlike stress testing, which pushes past normal limits to find the breaking point, load testing answers a narrower question: does this hold up at the traffic we actually expect?

Percentile latency (commonly p95 or p99) reports the response time below which a given percentage of requests fall — p95 of 200ms means 95% of requests were faster than 200ms. It's a far more useful performance metric than a simple average, which hides how bad the worst experiences actually are.

A performance baseline is a recorded set of performance metrics — response times, throughput, resource usage — captured under known, controlled conditions, used as the reference point every future measurement gets compared against to detect improvement or regression.

Performance testing measures how a system responds under a given workload — speed, stability, resource usage — covering the broader category that load, stress, spike, and soak testing are all specific types of. It exists to answer "how does this behave under realistic and extreme conditions," not just "does it work."

The ramp-up period is the time a load test takes to gradually increase simulated traffic from zero to its target level, rather than launching all virtual users simultaneously. It exists because real traffic growth is rarely instantaneous, and testing an instant, unrealistic spike measures a different (and less common) failure mode.

Response time is the total time between a request being sent and the complete response being received — the end-to-end metric users actually experience, encompassing network latency, server processing time, and data transfer. It's the most commonly reported, and most commonly misreported, performance metric.

Scalability testing measures how well a system's performance holds up as load increases, and whether adding resources (more servers, more database capacity) actually produces a proportional performance improvement. It answers "can this grow," distinct from capacity testing's "what's the current maximum."

Soak testing (also called endurance testing) runs a system under sustained load for an extended period — hours or days rather than minutes — to catch problems that only emerge over time, like memory leaks, resource exhaustion, or gradual performance degradation invisible in a short test.

Spike testing evaluates how a system responds to a sudden, sharp increase in load — far faster than a gradual ramp-up — mimicking scenarios like a flash sale, a viral social media mention, or a breaking news event driving an instant traffic surge.

Stress testing pushes a system beyond its normal or expected operating limits to find its actual breaking point and observe how it fails — gracefully, with clear errors and no data loss, or catastrophically, with crashes and corruption. It's about finding and characterizing failure, not avoiding it.

Think time is the simulated pause a virtual user takes between actions during a load test — the time a real person spends reading a page, deciding what to click next, or typing — included specifically to make simulated traffic behave more like genuine human usage rather than an unrealistic, non-stop request hammer.

Throughput is the number of requests, transactions, or operations a system can process in a given period of time — typically measured in requests per second — describing overall system capacity rather than the experience of any single request, which is what response time and latency measure instead.

Volume testing evaluates how a system performs when handling a large quantity of data — a huge database, a massive file upload, a bulk import of millions of records — rather than a large number of concurrent users, which is what load testing focuses on instead.