Performance testing scenarios

Before you run a performance test, you need to know what you're testing and why. Not every test is the same. A test that checks whether your application supports daily traffic is very different from a test that finds the exact point where it breaks.

This topic describes common test types and helps you choose the right one for your situation.

Test types

Each test type targets a different risk. The following table helps you choose the right one:

Type

Typical use case

Notes

Load

Verify that your application has acceptable response times for normal daily usage.

This is your baseline. Run it first, because if everyday traffic already causes issues, nothing else matters yet. For example, simulate 500 users during a typical business day.

Peak load

Confirm your system survives the busiest moments: month-end, Black Friday, payroll runs.

Simulates the highest traffic you expect at predictable times. For example, simulate 2,000 users during month-end closing.

Spike

Check whether your system can absorb a sudden, massive traffic increase.

A marketing campaign just went viral, or a news article is driving unexpected traffic. For example, jump from 200 to 5,000 users in under a minute.

Stress

Find your system's absolute limit by adding load until something breaks.

Shows which component fails first (database, application server, or network) and whether the system degrades gracefully. For example, ramp up to 10,000 users.

Soak / Endurance

Catch problems that only surface over time: memory leaks, connection pool exhaustion, disk space.

Runs a moderate load over hours or days. A 30-minute test won't find these. For example, run a steady load for 8 hours and compare response times at the start and end.

Failover

Simulate the loss of a server, node, or data center while your application is under load.

Many teams assume failover works because it's configured, but that's not the same as proving it. For example, take a database node offline while 1,000 users are active.

Batch mix

Check whether background jobs (imports, reports, ETL) interfere with online user traffic.

A data import kicks off while 500 users are active, and suddenly everyone sees timeouts. For example, start a data import during peak usage and measure the effect on response times.

Geographic

Check how distance, CDN behavior, and regional infrastructure affect performance.

Your users in Germany see fast response times, but your users in Brazil complain about 3-second delays. For example, generate load from Europe, North America, and Asia simultaneously.

What's next

Here's where to go after you've chosen your test type: