Does one hot cell slow down the whole city, or only the people standing in it?
Taxi backend at the end of a match at Luzhniki
Holds ~320 req/s on short steps (3.3 min); ~800 req/s degraded, not confirmed
Failed checks: Create the order response checks 99.9 % < 100 %, Driver position ping response checks 99.9 % < 100 %, ETA from the nearest drivers response checks 99.9 % < 100 % and 2 more.
- Holds
- ~320req/s
- measured over 3.3 min
All 7 steps checked at this rate
rate steps of 71 s–4 min · checks: 198 passed, 12 failed, 0 too little data, 0 not run · sent 99 % 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 ~320 and 1,000 req/s.
70% of riders stand within 800 m of the stadium and 30% of the pings come from drivers waiting there: one geo cell takes most of the load.
Example: a real CapacityLab Load Run against a taxi backend we host
Test setup
Where the limit lies
Each dot is a rate the backend was held at for at least a minute and a half. It passes when every call with enough samples keeps its p95 latency inside the bound and errors under 1%; a rare call with too few samples at that rate is shown as missing, not as passed.
- Held for 30 min256 req/s
Checks failed at a higher step, but the evidence does not confirm degradation or establish an upper limit. A separate confirmation test is needed.
- Latency bound
- p95 ≤ 500 ms
Planned against delivered
The search climbs a staircase of rates. At each step our generators sent the planned rate; the bars show what the backend actually answered, and its p95 latency at that step.
| Planned | Delivered | p95 | Errors | Result |
|---|---|---|---|---|
| 40 | 41.2 | 30 ms | 0% | Held |
| 80 | 81.8 | 50 ms | 0% | Held |
| 160 | 161 | 50 ms | 0% | Held |
| 320 | 318 | 50 ms | 0% | Held |
| 800 | 794 | 200 ms | 0.06% | Degradation unconfirmed |
- Create the order: responses failed their checks.
- Driver position ping: responses failed their checks.
- ETA from the nearest drivers: responses failed their checks.
- Find drivers nearby: responses failed their checks.
- Route and price: responses failed their checks.
- Check surge in the cell: responses failed their checks.
Which call slowed down first
p95 latency of each call at each rate, against the bound. The call the Result names as limiting is marked.
| Call | Share | 80 req/s | 160 req/s | 320 req/s | 800 req/s |
|---|---|---|---|---|---|
Driver position pingGET /tile38/SET+fleet+d00001+POINT+55.7558+37.6173 | 49% | 50 ms | 50 ms | 50 ms | 200 ms0.1% errors |
Geocode the destinationGET /photon/api | 9.8% | 50 ms | 30 ms | 50 ms | 150 ms0.1% errors |
Find drivers nearbyGET /tile38/NEARBY+fleet+LIMIT+5+POINTS+POINT+55.7558+37.6173+2000 | 9.8% | 50 ms | 50 ms | 50 ms | 200 ms0.1% errors |
Route and priceGET /osrm/route/v1/driving/37.6173,55.7558;37.5537,55.7158 | 9.8% | 30 ms | 30 ms | 30 ms | 100 ms0% errors |
Check surge in the cellGET /tile38/NEARBY+orders+COUNT+POINT+55.7158+37.5537+1000 | 9.8% | 50 ms | 50 ms | 50 ms | 200 ms0.1% errors |
ETA from the nearest driversGET /osrm/table/v1/driving/37.6100,55.7500;37.6200,55.7600;37.6173,55.7558 | 5.9% | 30 ms | 30 ms | 50 ms | 100 ms0.1% errors |
Create the orderGET /tile38/SET+orders+o0000000000000000+EX+900+POINT+55.7558+37.6173 | 5.9% | 50 ms | 50 ms | 50 ms | 300 ms0.1% errors |
p95, SLO ≤ 500 ms
Holding it for longer
A capacity search finds the limit in minutes. A 30-minute load test at a rate below it shows whether the backend keeps holding while orders pile up and the busy cells stay busy.
- Find the limitLimit not confirmedHolds 320 req/s; upper bound not establishedOct 2, 2026, 15:22 UTC
- Hold 30 minHeld255 req/s delivered, p95 50 ms, errors 0%Oct 2, 2026, 18:13 UTC
What we saw on our own servers
This is the one part a Report does not contain: we host this backend, so we can read the hosting metrics of each of its services. On your application you read your own dashboards; CapacityLab measures from the outside.
- Front door (Caddy)1.09 vCPUMemory peak 79 MB
- Geo database (Tile38)1.64 vCPUMemory peak 187 MB
- Routing (OSRM)0.21 vCPUMemory peak 227 MB
- Geocoder (Photon)0.85 vCPUMemory peak 8,162 MB
Geo database (Tile38) was the busiest service: its CPU peaked at 1.64 vCPU, ahead of Front door (Caddy) at 1.09.
None of 314,516 requests ended with a server error.
What you would do next
- Confirm before you plan
Run a load test at 320 req/s for 30 minutes: the search advises it as the rate to confirm next, and only the confirmation shows whether every call keeps its bound.
- Watch your side while it runs
Keep your own dashboards open during the run. The report says which call 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 CPU and memory of each service come from its Railway metrics; the error count, when shown, from the front door's access log.
Identifiers and checksums
| Load Run | Result digest | Computed |
|---|---|---|
52f512ce-a064-4e5e-9582-2bd0c87c5d86 | sha256:165b351f223b9ff57e483cc90557ca4bfafa3b964c4e35bf2e09dd611801fb02 | Oct 2, 2026, 15:39 UTC |
b03c332d-2453-4ea5-9de4-09edd18ecc9e | sha256:2d8309993955fe75a7383108b1d0fcbaeda728a08cd2daa8ed268d9a69c69cd3 | Oct 2, 2026, 18:43 UTC |