Volume test
A volume test measures how your system performs when it processes large data sets — not large numbers of concurrent users, but large amounts of data per request or a large number of database records behind the scenes. The question a volume test answers is: “Does performance degrade when the data grows?”
Before you start
Section titled “Before you start”- You can seed or migrate the target database or storage to a large-data-set state.
- You have established a load test baseline with a normal-sized data set.
- The large data set reflects a realistic future state (e.g., 10× current row count, large file uploads, paginated responses with deep pages).
What is a volume test?
Section titled “What is a volume test?”Volume tests differ from load tests and stress tests along the data dimension rather than the concurrency dimension:
| Dimension | Load test | Stress test | Volume test |
|---|---|---|---|
| What changes | VU count (normal → peak) | VU count (peak → beyond) | Data set size (normal → large) |
| VU count | Normal peak | Above peak | Normal (or modest) |
| Duration | 10–30 min | Until failure | Long enough to process data |
Common volume test scenarios:
- Large payload uploads — POST requests with 10–100 MB bodies.
- Deep pagination — fetching page 10,000 of a 1M-row result set.
- Batch processing — a background job that processes 1M records nightly.
- Report generation — an API endpoint that aggregates data across millions of rows.
- Large CSV imports — data entities with 100k+ rows.
How to run a volume test in MaxoPerf
Section titled “How to run a volume test in MaxoPerf”Load profile
Section titled “Load profile”| Parameter | Value |
|---|---|
| Virtual users (VUs) | Modest (10–50 VUs) — the data size is the variable |
| Duration | Long enough to observe degradation (15–30 min minimum) |
| Data set | Large: seed DB or use large test file |
| Stop mode | Duration or iterations |
| Locations | 1–2 (consistent with baseline test) |
Console walk-through
Section titled “Console walk-through”-
Prepare the large data set in your staging environment (seed scripts, database migrations, or pre-uploaded large files).
-
Create a test named
api-volume-large-datasetwith the same scenario as your load-test baseline, but reference the large-data-set seed:execution:- executor: jmeterconcurrency: 20ramp-up: 1mhold-for: 20mscenario: volume-reportscenarios:volume-report:requests:- url: https://api.staging.example.com/v1/reports/summary?from=2020-01-01&to=2026-01-01label: generate-report- url: https://api.staging.example.com/v1/runs?page=500&per_page=100label: deep-pagination -
If your scenario involves large file uploads, attach the test data via MaxoPerf’s Data entities and reference it in your test scenario. See CSV data-driven test.
-
Set the VU count to a modest number (20 VUs) — you are measuring data-volume impact, not concurrency impact.
-
Run and compare the result against the baseline test (same VU count, small data set) to quantify the degradation.
How to read the result
Section titled “How to read the result”The key question is not “does the test pass?” but “how much slower is the system with large data versus small data?”
- Response time per request — compare p95 latency against the baseline (small data) run. A 2× increase in latency at the same VU count is a data-volume degradation signal.
- Throughput (RPS) — typically lower than baseline for the same VU count because each request takes longer.
- Error rate — watch for timeouts. Large queries or payloads often hit request timeout limits before returning an error.
Use MaxoPerf’s run comparison view to place the volume test result alongside the small-data baseline and read the delta chips.
Do / don’t
Section titled “Do / don’t”| Do | Don’t |
|---|---|
| Keep VU count constant between baseline and volume runs | Increase VUs at the same time as increasing data size |
| Use realistic large-data scenarios (not artificially extreme) | Use 1TB payloads to “test the limit” — test what users will actually create |
| Compare against a small-data baseline run | Draw conclusions from an absolute latency number without a comparison |
| Investigate slow queries with DB-side profiling after the test | Optimise the wrong layer before confirming where the bottleneck is |
Where to go next
Section titled “Where to go next”- Configuration test — compare performance across different infrastructure configurations (e.g., with and without a query cache).
- Cookbook: CSV data-driven test — use MaxoPerf data entities to inject large data sets into your test scenario.
- Foundations: Core metrics explained — understand what throughput and latency mean when data volume is the variable.