How much ping and search traffic does the geo backend take before dispatch slows down?
Taxi backend on a normal evening
Holds ~800 req/s on short steps (4 min); no failure below
- Holds
- ~800req/s
- measured over 4 min
All 7 steps checked at this rate
rate steps of 71 s–4 min · checks: 148 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.
20,000 drivers across Moscow send their positions; for every ten pings one rider looks for a car, and half of the riders order.
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.
- Did not hold 30 min792 req/s
- 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 | 38.8 | 50 ms | 0% | Held |
| 80 | 79.5 | 50 ms | 0% | Held |
| 160 | 161 | 50 ms | 0% | Held |
| 320 | 317 | 50 ms | 0% | Held |
| 800 | 797 | 200 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 | 67% | 50 ms | 50 ms | 300 ms |
Geocode the destinationGET /photon/api | 6.7% | 50 ms | 50 ms | 150 ms |
Find drivers nearbyGET /tile38/NEARBY+fleet+LIMIT+5+POINTS+POINT+55.7558+37.6173+2000 | 6.7% | 50 ms | 50 ms | 200 ms |
Route and priceGET /osrm/route/v1/driving/37.6173,55.7558;37.5537,55.7158 | 6.7% | 30 ms | 30 ms | 150 ms |
Check surge in the cellGET /tile38/NEARBY+orders+COUNT+POINT+55.7158+37.5537+1000 | 6.7% | 50 ms | 50 ms | 200 ms |
ETA from the nearest driversGET /osrm/table/v1/driving/37.6100,55.7500;37.6200,55.7600;37.6173,55.7558 | 3.3% | 30 ms | 50 ms | 150 ms |
Create the orderGET /tile38/SET+orders+o0000000000000000+EX+900+POINT+55.7558+37.6173 | 3.3% | 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, 15:02 UTC
- Hold 30 minDid not hold792 req/s delivered, p95 150 ms, errors 0%Oct 2, 2026, 17:14 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.14 vCPUMemory peak 70 MB
- Geo database (Tile38)0.45 vCPUMemory peak 167 MB
- Routing (OSRM)0.18 vCPUMemory peak 227 MB
- Geocoder (Photon)0.68 vCPUMemory peak 8,156 MB
Front door (Caddy) was the busiest service: its CPU peaked at 1.14 vCPU, ahead of Geocoder (Photon) at 0.68.
None of 314,699 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 |
|---|---|---|
178694df-a385-4d7f-8fb7-d4b96fc6fd7f | sha256:0bdbf8fba7016174817dda1293350abc7c38656010e9aa48af58ef0d90e802a6 | Oct 2, 2026, 15:18 UTC |
5c45faed-d094-49e4-a715-e7fb6f5c8bce | sha256:9b9892534d77f40a534f519ff98b31ad5b253c6290eb5a3f582c1d4d0881f7cc | Oct 2, 2026, 17:46 UTC |