Multi-threaded setup

I’ve been running the internal osrm-backend C++ API in the past, and recently came across that it’s not supposed to be run in production. On my way to migrate to node-osrm, I came across an issue: I can’t get a setup to work that uses more than ~1.5 CPU threads.

As nodejs is single-threaded, I was using the nodejs internal cluster module, and I also tried load-balancing requests using haproxy to two different instances of node-osrm on the same machine. I’m using var osrm = new OSRM(); to access the map data via SHM (loaded via osrm-datastore).

While both approaches succeed in spawning multiple instances of osrm-node and all instances are retrieving and processing requests, the overall CPU load on the server is still roughly the same as with the single node-osrm setup. I therefore assume that there’s a lock somewhere in the osrm-node -> libosrm techstack preventing parallel use.

How do you guys run node-osrm in production? Are you just relying on a single core, or is there something I missed?

[TheMarex]

@chr4 actually we tried to reproduce this and saw a similar behavior. @daniel-j-h is working on a fix that should utilize the all the cores using nan::AsyncWorker instead of hooking into the libuv thread pool directly.

[f3d0r]

Thanks for the advice! Is there anything I can do to allow SSH-type behavior with the node.js wrapper for OSRM? Also (this might be better in a separate issue), but is it possible to use MLD-compiled .osrm files for node-osrm?