56a427f839
A request to osrm-routed can be assigned to a thread which is currently busy processing another request, even when there are other threads/cores available. This unnecessarily delays the response, and can make requests appear to hang when awaiting CPU intensive requests to finish. The issue looks like a bug in Boost.Asio multithreaded networking stack. osrm-routed server implementation is heavily influenced by the HTTP server 3 example in the Boost.Asio docs. By upgrading to Boost 1.70 and updating the server connections to match the example provided in the 1.70 release, the problem is resolved. The diff of the changes to the Boost.Asio stack are vast, so it's difficult to identify the exact cause. However the implementation change is to push the strand of execution into the socket (and timer) objects, which suggests it could fix the type of threading issue we are observing. |
||
|---|---|---|
| .. | ||
| contractor | ||
| customizer | ||
| engine | ||
| extractor | ||
| guidance | ||
| nodejs | ||
| osrm | ||
| partitioner | ||
| server | ||
| storage | ||
| updater | ||
| util | ||