OSRM is the performance monster out there. Sounds more like you have smth mis-configured.

Best to share a lot more details, e.g. platform, commands to run OSRM, graph extent, endpoint (route/table?), what's the approx average distance between locations etc.?

12 mins could be the case for 200 thousand locations. "The application" (assuming you're not talking about docker but osrm-*) has no hard-coded memory limit. It loads whatever the graph size statically and dynamically whatever is needed to do the expansion (quite low). So the 8GB is probably the graph. But again, impossible to guess what's going on without more details.

@nilsnolde There are several different regions of Brazil, some points can be more than 2000 kilometers between them. I executed the same commands as in the documentation to run using cmake, and made the request for standard port 5000 via GET passing the coordinates
Below is an example object before assembling the request to be more specific, but when I assemble a request with more than 200 points I am having this problem with the slowness of routing.

{
"latitude": -26.0922364,
"longitude": -51.6166878,
"region": 0,
},
{
"latitude": -28.9216045,
"longitude": -50.1799525,
"region": 0,
},
{
"latitude": -24.4931997,
"longitude": -46.9945173,
"region": 0,
},
{
"latitude": -26.9195567,
"longitude": -48.0988025,
"region": 0,
},

/route or /table? not super familiar with osrm, but a many:many table shouldn't have a problem with that. a route with > 200 waypoints, where lots of them have multiple thousand km apart is a different story as that happens sequentially. still, 12 mins even valhalla would beat in that scenario very likely, so smth strange is going on there.

are you saying that up to 200 waypoints it's quick and above that performance suddenly breaks down?

also what's that "region"? are you splitting osm data? i.e. you're not building entire brazil but island-ish regions of it in a single graph? are you sure connectivity/topology is properly preserved?

@nilsnolde
Route

As a rule, no, as more points are added, it grows exponentially, I used it from 200 points onwards, as that's when it starts to get really bad for the user. 35 waypoints take approximately 15 seconds, 90 waypoints take just over a minute, 150 waypoints take approximately 4 minutes, and 200 waypoints take approximately 12 minutes.
Regarding the region, I don't go to OSMR, I've already downloaded the complete Brazil map, so there's no need to divide and group again.

I put it to route 350 points, and it doesn't exceed 8GB, even so it's taking a long time.
Screenshot from 2024年02月19日 15-19-00

the last thing that comes to my mind is possibly that it's using excessive swapping for some reason. anything else running on that machine? 12 gb should be plenty for brazil which has 1.6 gb PBF.

what's the output of grep '^Swap' /proc/meminfo? if there's smth in there, then: when you start the osrm executable, look up its PID (process ID) and then monitor what it's using on swap file while processing one of those big requests with grep VmSwap /proc/<PID>/status.

if there's no clue there, I give up:) but there's many others here with tons of more experience/knowledge on osrm.

@nilsnolde

I listed the commands while it is doing the routing

root@srv-OSRM:~# grep '^Swap' /proc/meminfo
SwapCached: 0 kB
SwapTotal: 4096000 kB
SwapFree: 4096000 kB

root@srv-OSRM:~# grep VmSwap /proc/359/status
VmSwap: 0 kB
No problem, it's something I'm starting to tinker with now too

@optrack2 Can you supply an example URL that someone can use to try to reproduce the issue?

@danpat
I'm looping for each group of points.
http://192.168.1.197:5000/route/v1/driving/-48.0643025,-24.9125567;-43.0426162,-22.6604221?overview=full&alternatives=false&steps=false&geometries=polyline&annotations=false

I'm using Ubuntu 22.04, if I change to FreeBSD it may upgrade performance?

@optrack2 If you does not need all the route details at this computation step. Just use the table API en point, aka matrix. It is matter of seconds, or less.

https://github.com/Project-OSRM/osrm-backend/blob/master/docs/http.md#table-service