Volume Testing¶
Volume testing answers one question: when the database has months of real data, how long does it take one person to open a list screen?
It is not a “many users at once” test. That is load testing. Here we add rows (factories, machines, tasks) and measure load time with a single user so slowness from data size is separate from slowness from traffic.
Latest numbers and fix status: optimization.md. Plain-language summary: general-volume-testing.md.
Latest results (1 July 2026)¶
Test size: 200 factories, 4,000 machines, 5,000 tasks (six-month projection), one user, local server.
| Screen | Load time before fixes | Load time after task-list fix | Status |
|---|---|---|---|
| Task list | 437 ms | 23 ms | Fixed |
| Factory list | 345 ms | 24 ms | Fixed |
| Machine list | 351 ms | 320 ms | Fixed |
| My profile | 3 ms | 2 ms | OK (control) |
437 ms is under half a second. 23 ms is effectively instant for the user.
Repeat run over one minute (still one user): task list went from 417 ms to 60 ms per load.
Run #1 (26 June) found the task-list problem. Run #2 (29 June) confirmed the task-list fix after re-seeding test data. Run #3 (1 July) confirmed machine-list count removal: p95 351 ms → 320 ms; query count stays bounded. Artifacts: docs/volume-results/run-20260629-171059/, docs/volume-results/run-20260701-121011/.
What each run does¶
- Count rows in the database before adding test data.
- Measure load times on a nearly empty database (baseline).
- Insert test data for the chosen tier (default: six months / T1).
- Measure again with the same screens and limits.
- Automated one-user run for one minute (same screens as the mobile app mix).
- Query-count checks — confirms the server is not running hundreds of separate database queries per page.
All primary timings use one client only so results reflect data size, not concurrent traffic.
Screens measured¶
Same mix as mobile load tests:
| Screen | Request | Why it is included |
|---|---|---|
| Factory list | GET /api/factories?limit=300 |
Heavy list; 25% of mobile traffic |
| Machine list | GET /api/machines?limit=100 |
Pagination; 25% |
| Task list | GET /api/tasks?limit=100 |
Was the main scaling problem; 25% |
| My profile | GET /api/users/me |
Control — should stay fast as data grows |
Data tiers¶
| Tier | Meaning | Factories | Machines | Tasks |
|---|---|---|---|---|
| T0 | Baseline (empty or minimal) | ~1 | ~1 | 0 |
| T1 | ~6 months | 200 + existing rows | 4,000 + existing | 5,000 |
| T2 | ~12–18 months (not run yet) | 1,000 | 25,000 | 25,000 |
Test rows use the voltest_ prefix. Remove them without touching real data:
venv/bin/python scripts/volume/seed_volume_db.py clean
How to run¶
You need: PostgreSQL with migrations applied, a loadtest user, the API running locally, and k6 installed.
Start the API:
venv/bin/uvicorn main:app --host 127.0.0.1 --port 8000
Full T1 run:
export BASE_URL=http://127.0.0.1:8000
export K6_USERNAME=loadtest
export K6_PASSWORD=your_loadtest_password
export VOLUME_TIER=t1
./scripts/volume/run_volume_test.sh
Output goes to docs/volume-results/run-YYYYMMDD-HHMMSS/. Copy the load times into optimization.md.
Manual steps (same as the script):
venv/bin/python scripts/volume/seed_volume_db.py counts
venv/bin/python scripts/volume/measure_endpoints.py --tier-label t0 --output /tmp/t0.json
venv/bin/python scripts/volume/seed_volume_db.py seed --tier t1
venv/bin/python scripts/volume/measure_endpoints.py --tier-label t1 --output /tmp/t1.json
K6_SCENARIO=volume-baseline k6 run scripts/load/api-load.js
venv/bin/python -m pytest tests/test_volume_query_efficiency.py -q
Tools¶
| Script | Role |
|---|---|
scripts/volume/seed_volume_db.py |
Insert or remove test data |
scripts/volume/measure_endpoints.py |
Timed requests, one user (3 warmup + 15 samples per screen) |
scripts/volume/run_volume_test.sh |
Runs the full sequence above |
scripts/load/api-load.js |
One-user confirmation run (K6_SCENARIO=volume-baseline) |
tests/test_volume_query_efficiency.py |
Fails if query count grows with row count |
Run history¶
| Date | Folder | Note |
|---|---|---|
| 2026-06-26 | docs/volume-results/run-20260626-051613/ |
T1 baseline; task list 437 ms |
| 2026-06-29 | docs/volume-results/run-20260629-171059/ |
Task list fix verified; 23 ms |
Limits¶
- Local machine, single server process, localhost — production will differ.
- T1 (~5k tasks) catches application-layer query problems; very large tables (100k+ rows) may need T2.
- A passing load test on an empty database does not predict list speed at T1. Run both.