When demand outruns the cars nearby, which call gives first?
Taxi backend at rush hour in rain
Holds 800 req/s on short steps (4 min); no failure below
- Holds
- 800req/s
- measured over 4 min
All 9 steps checked at this rate
rate steps of 71 s–4 min · checks: 188 passed, 0 failed, 2 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 800 and 1,000 req/s.
Twice the riders and three times the orders of a normal evening. Half of the dispatches find no car close enough and search again within 4 km, so more ETA tables are computed.
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.
- 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 | 40.9 | 50 ms | 0% | Held |
| 80 | 78.6 | 75 ms | 0% | Held |
| 160 | 160 | 50 ms | 0% | Held |
| 320 | 319 | 50 ms | 0% | Held |
| 800 | 796 | 150 ms | 0% | Held |
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 | 160 req/s | 320 req/s | 800 req/s |
|---|---|---|---|---|
Driver position pingGET /tile38/SET+fleet+d00001+POINT+55.7558+37.6173 | 44% | 50 ms | 75 ms | 150 ms |
Geocode the destinationGET /photon/api | 8.9% | 50 ms | 50 ms | 100 ms |
Find drivers nearbyGET /tile38/NEARBY+fleet+LIMIT+5+POINTS+POINT+55.7558+37.6173+2000 | 8.9% | 50 ms | 50 ms | 150 ms |
Route and priceGET /osrm/route/v1/driving/37.6173,55.7558;37.5537,55.7158 | 8.9% | 50 ms | 50 ms | 100 ms |
Check surge in the cellGET /tile38/NEARBY+orders+COUNT+POINT+55.7158+37.5537+1000 | 8.9% | 50 ms | 50 ms | 150 ms |
ETA from the nearest driversGET /osrm/table/v1/driving/37.6100,55.7500;37.6200,55.7600;37.6173,55.7558 | 6.7% | 50 ms | 50 ms | 100 ms |
Search again within 4 kmGET /tile38/NEARBY+fleet+LIMIT+5+POINTS+POINT+55.7558+37.6173+4000 | 3.3% | 50 ms | 50 ms | 150 ms |
ETA after the wider searchGET /osrm/table/v1/driving/37.6100,55.7500;37.6200,55.7600;37.6173,55.7558 | 3.3% | 50 ms | 50 ms | 100 ms |
Create the orderGET /tile38/SET+orders+o0000000000000000+EX+900+POINT+55.7558+37.6173 | 6.7% | 50 ms | 50 ms | 150 ms |
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 limitNo limit in the rangeHolds 800 req/s on short steps (4 min); no failure belowOct 2, 2026, 16:55 UTC
- Hold 30 minPlanned
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.15 vCPUMemory peak 67 MB
- Geo database (Tile38)0.47 vCPUMemory peak 165 MB
- Routing (OSRM)0.36 vCPUMemory peak 227 MB
- Geocoder (Photon)0.8 vCPUMemory peak 8,311 MB
Front door (Caddy) was the busiest service: its CPU peaked at 1.15 vCPU, ahead of Geocoder (Photon) at 0.8.
None of 314,338 requests ended with a server error.
What you would do next
- Confirm before you plan
Run a load test at 800 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 |
|---|---|---|
22dbb2c4-36ab-4374-b2f3-915f60faa33f | sha256:d177825baa5ea00c3fd990f7f2dccedb8c9e8aae03f2bfed1c215b89af0df345 | Oct 2, 2026, 17:11 UTC |