Performance testing types, workload models and p95

Six types of performance test

Each type answers one question, and mixing them in one run answers none. A load test asks whether the system meets its targets at expected traffic. A stress test asks where it breaks and how it fails. A soak test asks whether it degrades over hours. A spike test asks whether it survives a sudden surge and recovers. A scalability test asks how much you gain by adding capacity. A volume test asks what happens when the data, not the traffic, is large. The table gives each its goal, its traffic shape, its duration and the signal that means it passed.

The six performance test types, one question each.
Type	Goal	Traffic shape	Duration	Pass signal
Load	Meet targets at expected peak	Ramp to peak, hold steady	30 to 60 minutes	p95 and error rate within target for the whole hold
Stress	Find the breaking point and failure mode	Ramp beyond peak until failure	Until failure plus recovery	Knee is above 1.5x expected peak; failure is graceful and recovers
Soak (endurance)	Expose leaks, growth, exhaustion	Steady at 70 to 80 percent of peak	8 to 72 hours	No upward drift in response time or memory after warm-up
Spike	Survive a sudden surge	Jump from baseline to 3x to 10x in seconds	10 to 20 minutes	Errors stay bounded; recovery to baseline within an agreed time
Scalability	Measure gain per unit of capacity	Same load at 1x, 2x, 4x capacity	3 runs of 30 minutes	Throughput scales near linearly; the bottleneck is identified
Volume	Behavior with large data sets	Normal traffic against 10x data	30 to 60 minutes	Query times stay within target as tables grow

Workload modelling from production data

A workload model states who does what, how often, at what peak. It comes from production, never from opinion. Pull one representative week of access logs, count requests by endpoint or transaction, find the peak hour, and convert to a transaction mix. If the product is new, use the business plan's user numbers and a comparable product's behavior, and label the model as an assumption to be replaced after launch. The worked example below is a retail checkout service whose logs showed a peak of 1,200 requests per minute on a Thursday evening.

A worked transaction mix for a checkout service at 1,200 requests per minute peak.
Transaction	Share of peak traffic	Requests per minute at peak	Think time between steps	Notes
Browse catalog	55 percent	660	5 to 15 seconds	Cacheable, read-only
Search	20 percent	240	3 to 10 seconds	Database heavy, long-tail queries
Add to basket	12 percent	144	2 to 8 seconds	Writes to session store
Checkout	8 percent	96	20 to 60 seconds	Calls payment provider; the business-critical path
Account and order history	5 percent	60	5 to 20 seconds	Authenticated, low volume, slow queries

Three details separate a usable model from a toy. Think time must be realistic, because 200 virtual users with zero think time generate the load of 2,000 real users and break the system in a way real users never would. Data must vary: a search test that always searches the same word measures the cache, not the database. And the model needs a growth factor: test at 1.5x to 2x the observed peak so that the result still holds next quarter.

The results that matter, and why averages lie

Report five numbers: p50, p95 and p99 response time, throughput in requests per second, and error rate. Add resource saturation (CPU, memory, connection pool, disk queue) for the tier that limits capacity. Then stop. The mean response time is not on the list because it hides the users you should care about. A service where 95 requests take 200 ms and 5 take 12 seconds has a mean of 790 ms, which sounds acceptable, and a p95 of 200 ms with a p99 of 12 seconds, which tells you 1 in 20 customers waits long enough to leave. Percentiles describe the experience of real users; the mean describes nobody's.

p50 shows the typical experience and is the number to watch for regressions between builds.
p95 is the usual contractual target; it covers 19 of every 20 requests.
p99 exposes tail latency from garbage collection pauses, lock contention and cold caches; a p99 more than 5x the p50 is a design smell.
Throughput that stops rising while load rises means you have found the knee.
Error rate above 0.1 percent under load usually means timeouts, and timeouts are the customer's experience of slowness.

Environment parity

A performance result is only as good as the environment's resemblance to production. Match the instance class and count, the database size (a 10,000-row test table says nothing about a 40-million-row production table), the network path including any gateway or firewall, and the third-party dependencies, which should be stubbed with realistic latency rather than left live. Where full parity is unaffordable, run at half scale and half load, and state plainly that the result assumes linear scaling, which the scalability test then verifies. Never extrapolate from a shared test environment where another team's job may have been running.

How to set targets

Targets come from three places: user research on tolerable wait (roughly 1 second before attention drifts, 10 seconds before abandonment), business commitments in contracts, and the current production baseline. A reasonable first set for a customer-facing web service is p95 under 800 ms and p99 under 2 seconds for reads, p95 under 1.5 seconds for writes such as checkout, error rate under 0.1 percent, and no degradation over an 8-hour soak. Tie each target to a transaction in the model rather than to the system as a whole, because a slow account history page is tolerable and a slow checkout is not. When a target is missed, rank the fix with the same risk-based logic as any functional defect.

Rule of the knee

Find the knee in a stress test before you set load test targets. If the knee sits at 1,400 requests per minute and peak is 1,200, you have 17 percent headroom, which is a capacity finding worth more than any pass or fail.

Reporting

A performance report is read by people who will not open the raw data, so lead with the verdict and the headroom. One page: the workload model used, the environment and how it differs from production, a table of each transaction against its target with p50, p95, p99 and error rate, the response-time-against-load chart with the knee marked, and the bottleneck identified with evidence. Keep every run's results so that the next release can be compared, and treat unexplained run-to-run variance above 10 percent the way you would treat flaky tests: as a problem with the harness until proven otherwise. Definitions of the metrics are in the glossary.

Common questions

What is the difference between load testing and stress testing?

Load testing checks the system at expected traffic and asks whether targets are met. Stress testing pushes past expected traffic to find where and how it breaks. Load is a pass or fail; stress is a measurement.

How many virtual users do I need?

Derive it from the model: requests per minute divided by requests per user per minute, which depends on think time. 1,200 requests per minute with 10 seconds average think time needs about 200 concurrent users.

Why does my test pass but production is slow?

Usually one of four reasons: unrealistic think time, repeated data hitting caches, a smaller database than production, or a shared environment. Check them in that order.

How long should a soak test run?

Long enough to cover at least two cycles of anything periodic: log rotation, cache expiry, scheduled jobs, garbage collection at full heap. Eight hours is a minimum; 24 to 72 hours for systems that stay up for weeks.

Should performance tests run in the pipeline?

A short load test (10 to 15 minutes at 50 percent of peak) can run nightly and catch regressions in p50. Full load, stress and soak tests belong on a schedule and before releases.

What is the difference between response time and latency?

Latency is the delay before the first byte; response time is the full time to complete the request. For a user, response time is what matters. Tools report both; make sure the target names the one you mean.

Performance testing: types, workload models and p95 results