Does the same shop carry more or less once its data has grown?
Online shop with a large catalog
Does not hold even ~31 req/s
Failed checks: Search errors 3.8 % > 1 %.
- Fails at
- ~31req/s
Checked 4 of 12 steps at this rate; 8 not checked — too few samples (< 100 in the window)
- Choose shipping
- Place the order
- Add to cart
- Start payment
- Open the payment session
- Load the region
- See shipping options
- Enter the address
rate steps of 1.6–5 min · checks: 106 passed, 37 failed, 17 too little data, 0 not run · sent 100 % of the plan · generator health not verified
Synthetic load sent from outside; your real traffic and server metrics are not part of it.
What to do next
- Search next between 6 and ~31 req/s.
50,000 products, 150,000 customers and 100,000 orders: a shop after a few busy years.
Example: a real CapacityLab Load Run against a shop we host
Test setup
Where the limit lies
Each dot is a rate the shop was held at for at least a minute and a half. It passes when every step of the visit with enough samples keeps its p95 latency inside the bound and errors under 1%; a rare checkout step with too few samples at that rate is shown as missing, not as passed.
- Held for 30 min18 req/s
- Held for 60 min18 req/s
- Held for 180 min18 req/s
- Held for 720 min18 req/s
- Slowed first
- Search
- Latency bound
- p95 ≤ 1.5 s
Planned against delivered
The search climbs a staircase of rates. At each step our generators sent the planned rate; the bars show what the shop actually answered, and its p95 latency at that step.
| Planned | Delivered | p95 | Errors | Result |
|---|---|---|---|---|
| 7.1 | 7.2 | 300 ms | 0% | Held |
| 12.7 | 12.4 | 300 ms | 0% | Held |
| 22.5 | 22.4 | 300 ms | 0.06% | Held |
| 30.7 | 31.3 | 300 ms | 0.43% | Broke |
| 39.2 | 38.3 | 300 ms | 1.31% | Broke |
| 40 | 38.9 | 400 ms | 1.55% | Broke |
| 50.1 | 46.6 | 300 ms | 2.45% | Broke |
| 64 | 59.8 | 400 ms | 3.84% | Broke |
- Search: 3.79% of requests failed, against 1% allowed.
- The whole visit: 1.31% of requests failed, against 1% allowed.
- Search: 10.9% of requests failed, against 1% allowed.
- 7 steps of the visit got less traffic than planned: visits slowed down and fell behind the schedule (lowest 77.8% of plan).
Which step slowed down first
p95 latency of each step of the visit at each rate, against the bound. The step the Result names as limiting is marked.
| Step of the visit | Share | 7.1 req/s | 12.7 req/s | 22.5 req/s | 30.7 req/s | 39.2 req/s |
|---|---|---|---|---|---|---|
Load the regionGET /store/regions | 2.9% | — | — | 30 ms | — | 50 ms |
Open categoriesGET /store/product-categories | 8.6% | — | 30 ms | 30 ms | 50 ms | 50 ms |
Browse the catalogGET /store/products | 29% | 50 ms | 50 ms | 75 ms | 75 ms | 75 ms |
SearchLimitingGET /store/products | 12% | — | 300 ms | 300 ms0.5% errors | 400 ms3.8% errors | 500 ms11% errors |
Open a productGET /store/products/{product_id} | 39% | 50 ms | 50 ms | 50 ms | 50 ms | 50 ms |
Add to cartPOST /store/carts | 2.9% | — | — | 300 ms | — | 400 ms |
Enter the addressPOST /store/carts/{cart_id} | 1.4% | — | — | — | — | — |
See shipping optionsGET /store/shipping-options | 1.4% | — | — | — | — | — |
Choose shippingPOST /store/carts/{cart_id}/shipping-methods | 1.4% | — | — | — | — | — |
Start paymentPOST /store/payment-collections | 0.7% | — | — | — | — | — |
Open the payment sessionPOST /store/payment-collections/{payment_collection_id}/payment-sessions | 0.7% | — | — | — | — | — |
Place the orderPOST /store/carts/{cart_id}/complete | 0.7% | — | — | — | — | — |
p95, SLO ≤ 1,500 ms
Holding it for longer
A capacity search finds the limit in minutes. Longer runs at a rate below it show whether the shop keeps holding: slow leaks, full queues and cold caches take time to show.
- Find the limitLimit found — provisionalHolds ~22 req/s on short steps (3.9 min), fails at ~40 req/sSep 30, 2026, 18:10 UTC
- Narrow the limitDoes not hold the first stepDoes not hold even ~31 req/sSep 30, 2026, 18:28 UTC
- Hold 30 minHeld18 req/s delivered, p95 300 ms, errors 0.02%Sep 30, 2026, 18:45 UTC
- Hold 1 hHeld17.9 req/s delivered, p95 300 ms, errors 0.01%Sep 30, 2026, 19:17 UTC
- Hold 3 hHeld18 req/s delivered, p95 300 ms, errors 0.01%Sep 30, 2026, 20:19 UTC
- Hold 12 hHeld18 req/s delivered, p95 300 ms, errors 0.03%Sep 30, 2026, 23:34 UTC
What we saw on our own servers
This is the one part a Report does not contain: we host this shop, so we can read its hosting metrics. On your application you read your own dashboards; CapacityLab measures from the outside.
- Application (Node.js)1.32 vCPUMemory peak 547 MB
- Database (PostgreSQL)8.03 vCPUMemory peak 2,580 MB
- Cache (Redis)0.01 vCPUMemory peak 25 MB
The database was the busier side: its CPU peaked at 8.03 vCPU while the application stayed at 1.32. Its CPU was not capped, so this shows where the work went, not that the database ran out; search over a catalog this large is database work and a likely place for visitors to queue, but locks and query plans were not measured.
915 of 35,927 requests ended with a server error.
What you would do next
- Confirm before you plan
Run a load test at 18 req/s for 30 minutes: the search advises it as the rate to confirm next, and only the confirmation shows whether every step keeps its bound.
- Watch your side while it runs
Keep your own dashboards open during the run. The report says which step slowed; your metrics say why.
- Change one thing, then compare
After a change, run the same test again and put the two reports side by side.
Your own copy of this report is one sign-up away
Sign up with your email. Your new account opens with this report and every other demo report inside, ready to compare with your own first run.
Where these numbers come from
Exported from the published Reports of these Load Runs. The shop's CPU and memory come from its Railway metrics; its error count from its own access log.
Identifiers and checksums
| Load Run | Result digest | Computed |
|---|---|---|
ed28262a-e4b5-4278-81c7-a128b8d93712 | sha256:f244ee250ef0881cbc9b18f94ed9669f754c7cb2d7bae9a3a4ca9d755319030c | Sep 30, 2026, 18:26 UTC |
2e4332f9-ae3e-4671-8f7c-240db5241ffe | sha256:a96f20e5a623c4ffeb0d1cc6ce0efef8136c2f20a9f116d66567a9b74045896d | Sep 30, 2026, 18:43 UTC |
0d9584f6-edec-4fb1-95d9-8c97ffd80f3d | sha256:ca759ad76b672bd41c422f75c5a9099ce6de33f4b0078d7a18278062944d58e6 | Sep 30, 2026, 19:15 UTC |
ee309538-e5a6-46c8-9233-4383d609f1e4 | sha256:82170146a1ad7806827c18ef7c9383f880c93fb18bb36809d81b452508ac40c2 | Sep 30, 2026, 20:17 UTC |
ae153ca1-e87c-44a5-8838-c6ee075c680d | sha256:7cf98c58b3d23a60ae0884f9b194a9d2d2e33a70e28e662276ce467978861b91 | Sep 30, 2026, 23:20 UTC |
918006d2-92ac-4850-bd14-127a2480bc2b | sha256:922be0f52c767948a9975074b2b8b95f24c287123c11dd1e6bba7bd944932cb0 | Oct 1, 2026, 11:39 UTC |