Optimization tips for large datasetsCopy link
Routing24 has no stop limit on any tier, and plans of one to two thousand stops solve in the browser, on your machine.
How runtime scalesCopy link
The time budget is chosen automatically from the plan size. Rough guide:
| Stops | Solve time |
|---|---|
| ~10 | ~3 seconds |
| ~100 | ~30 seconds |
| ~1000 | ~5 minutes |
| ~2000 | ~15 minutes |
The metrics strip shows TIME LEFT while it runs. There is no dial to trade time for quality; the budget scales with plan size. See Run the optimizer for the run mechanics.
Before solving starts, Routing24 fetches the travel-time and distance matrix for your locations from its servers. On large plans this preparation step adds a delay before the countdown starts.
What the solver needs from your machineCopy link
The computation is spread across parallel workers in your browser, using your CPU cores. Practical consequences:
- Keep the tab open until the run finishes.
- Keep the machine awake. Sleep pauses the workers; a 15-minute run needs sleep disabled.
- Close the browser developer console; it can slow the optimization significantly.
- More cores help. A desktop solves a 2000-stop plan faster than a laptop, and other heavy tabs compete for the same cores.
Modeling large plansCopy link
At large scale, the data matters more than the hardware:
- Use Available count, not copied rows. Ten identical vans should be one Fleet row with Available: 10, not ten rows. The solver treats interchangeable vehicles more efficiently than ten one-off types.
- Fewer distinct constraints. Every unique time window, tag combination, and per-order exception constrains the search further. Standardize where the business allows: one delivery window per customer group rather than a hand-picked window per order.
- Realistic shifts, not open-ended days. Tight but accurate shifts and windows cut the search space and produce routes drivers can run.
- Accurate service times. On 1000 stops, an over-estimated service time of 5 extra minutes is 80+ phantom hours that will push real orders into unassigned.
When to split the planCopy link
Keep orders in one plan as long as they compete for the same vehicles. Split when they do not:
- By day. Orders for different days do not belong in one solve. Multi-day planning with day offsets works, but if Tuesday's orders can never share a route with Monday's, two plans solve faster.
- By area. If the north and south zones have dedicated fleets and no vehicle ever crosses over, they are two independent problems. Solve them as two plans.
Do not split what shares vehicles: savings come from the overlap between territories, and a manual split removes them from the search. To start a second plan from the same fleet, use Copy vehicles on the My Plans page.
Constraint mistakes are easier to spot on 50 stops than on 2000. When building a big plan for the first time, import a slice, optimize, check the result, then run the full set. See Import from Excel or CSV.
Next stepCopy link
Reviewing large solutions uses the display controls and filter: Read the solution: ETAs, distance, load.