We don't use Stxxl during the query phase, but an SSD is recommended. We use an external memory storage for the R-Tree that we use for getting the closed street segment.
For matrix queries on MLD are about 2-3 times slower than on CH. Best, Patrick Baig, Tariq <[email protected]> schrieb am Do., 29. März 2018, 11:27: > Thanks for the suggestions Patrick, > > how do you think things would change if we needed trafic support? I guess > MLD is slower than CH, > could we compensate for that by putting the whole system on an SSD to make > the stxxl perform better? > > Thanks again, > tariq > > ---------------------------------------------------------------------------------- > > Tariq Baig-Meininghaus > > Researcher > > Max Planck Institute for Dynamics and Self-Organization > Department DCF/EcoBus > > Am Faßberg 17 > > 37077 GÖTTINGEN > GERMANY > > > Mail: [email protected] > > Web: www.ds.mpg.de, ecobus.fokos.info > > ________________________________________ > From: [email protected] [ > [email protected]] > Sent: Wednesday, March 28, 2018 2:00 PM > To: [email protected] > Subject: OSRM-talk Digest, Vol 63, Issue 11 > > Send OSRM-talk mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstreetmap.org/listinfo/osrm-talk > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OSRM-talk digest..." > > > Today's Topics: > > 1. Suggested hardware specs for server under heavy use (Baig, Tariq) > 2. Re: Suggested hardware specs for server under heavy use > (Patrick Niklaus) > 3. Re: OSRM 5.14.3 set kilometers long ways as small elements > (Daniel Patterson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Mar 2018 12:49:08 +0000 > From: "Baig, Tariq" <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [OSRM-talk] Suggested hardware specs for server under heavy > use > Message-ID: > <350c9baaf4e5894aa7907627b5508828d532f...@um-excdag-a03.um.gwdg.de > > > Content-Type: text/plain; charset="iso-8859-1" > > Dear all, > > we are currently working on a research project that uses osrm as a routing > backend. > Since we heavily rely on OSRM we would like to migrate it to a more > appropriate harware setup. > > What would be the recommended specs for a server that provides routing > for the whole of germany, > and can service order of 100 - 200 table requests per second? > > Greetings and thanks in advance, > > tariq > > > ---------------------------------------------------------------------------------- > > Tariq Baig-Meininghaus > > Researcher > > Max Planck Institute for Dynamics and Self-Organization > Department DCF/EcoBus > > Am Faßberg 17 > > 37077 GÖTTINGEN > GERMANY > > > Mail: [email protected] > > Web: www.ds.mpg.de, ecobus.fokos.info > > > > ------------------------------ > > Message: 2 > Date: Tue, 27 Mar 2018 14:41:18 +0000 > From: Patrick Niklaus <[email protected]> > To: Mailing list to discuss Project OSRM <[email protected]> > Subject: Re: [OSRM-talk] Suggested hardware specs for server under > heavy use > Message-ID: > < > cafxp+1p1ofr6_ea6pcviflau8pjqp5f4v4kwadz9gfno-gq...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hey Tariq, > > This heavily depends on the settings you use and the kind of requests. > For the car profile Germany should fit into 16GB of RAM, but I would > calculate some buffer depending on if you need the option to exclude > motorways and ferries. > I'll assume you don't need traffic support? Then using or Contraction > Hierarchy toolchain might be your best option. > > For the CPU requirement to get close to 200 req/sec it entirely > depends on the kind of request (how many input coordinates). > For a 100x100 matrix you can expect something like ~100ms on Germany, > that would put you at 10 req per core per second. > A 16 core system should probably get you in the right order of magnitude. > > Best, > Patrick > > > On Tue, Mar 27, 2018 at 12:49 PM, Baig, Tariq <[email protected]> > wrote: > > Dear all, > > > > we are currently working on a research project that uses osrm as a > routing backend. > > Since we heavily rely on OSRM we would like to migrate it to a more > appropriate harware setup. > > > > What would be the recommended specs for a server that provides routing > for the whole of germany, > > and can service order of 100 - 200 table requests per second? > > > > Greetings and thanks in advance, > > > > tariq > > > > > ---------------------------------------------------------------------------------- > > > > Tariq Baig-Meininghaus > > > > Researcher > > > > Max Planck Institute for Dynamics and Self-Organization > > Department DCF/EcoBus > > > > Am Faßberg 17 > > > > 37077 GÖTTINGEN > > GERMANY > > > > > > Mail: [email protected] > > > > Web: www.ds.mpg.de, ecobus.fokos.info > > > > _______________________________________________ > > OSRM-talk mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/osrm-talk > > > > ------------------------------ > > Message: 3 > Date: Tue, 27 Mar 2018 08:10:20 -0700 > From: Daniel Patterson <[email protected]> > To: Mailing list to discuss Project OSRM <[email protected]> > Subject: Re: [OSRM-talk] OSRM 5.14.3 set kilometers long ways as small > elements > Message-ID: > < > canvddsk075y44ocgtmxu8bqdcw1aj62hpgjhulg3pze+wrg...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi François, > > > I don't understand why flagging part of the graph as "small element" > prevent a route to be found. > > I guess you could describe this as a bug. What OSRM is trying to do is > always return a route. The current approach makes sure to snap the input > coordinates to edges on the same "strongly connected component", which > (usually) guarantees a route will be found. > > There's an older blog post by Denis here: > > https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8 > that explains the behaviour/problem that this snapping is intended to > solve. > > This behaviour makes sense for fully disconnected components - islands, > parks, etc. > > However, in your case, the components are weakly connected - there is a > one-way path in, and an A->B route could be found, but a B->A route would > not. > > This situation isn't really handled by the current approach. The Tarjan > SCC algorithm flags *strongly connected* graph regions (full connectivity > in both directions). We would need to do something quite different I think > in order to do correct snapping for weakly connected components as you have > in your graph. > > Generally in OSM, there aren't too many of these, and where they are, > they're usually a mapping error (one-way roads with no exits, etc). Given > that, I'm not sure it's worth spending time improving this behaviour for > use with OSM data. > > daniel > > > On Tue, Mar 27, 2018 at 1:58 AM, François Lacombe < > [email protected] > > wrote: > > > Hi Daniel, > > > > 2018-03-26 19:48 GMT+02:00 Daniel Patterson <[email protected]>: > > > >> Hi François, > >> > >> Yes, oneways onto your custom road network sound like exactly the kind > >> of thing that the small component algorithm ( > >> https://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected > >> _components_algorithm) would flag. If your custom network is <1000 > >> nodes, it would've been flagged previously. > >> > >> If you are only routing from the normal network *onto* your custom > >> network, then changing the component size like you've done is the > correct > >> fix here. Just be aware, if you start on your custom network, and try > to > >> return to the main network, you will get "NoRoute" errors, but it sounds > >> like that won't be a problem for you. > >> > > > > This is indeed what I look for, no problem to get "No route" errors, but > > only when network topology doesn't allow me to find one. > > I don't understand why flagging part of the graph as "small element" > > prevent a route to be found. > > > > I would agree to a potential downgrade of small elements versus normal > > ones, but a route have to be returned when it exists, haven't you? > > > > > >> I'm not sure what's up with the turn icons in the debug viewer - make > >> sure you've zoomed in far enough, turn icons only show up from Z12 and > >> higher. > >> > > > > Yes, I look between zoom 12 and 14 > > Still no turn icons > > > > I'm wondering if it's only a display issue or a more serious problem in > my > > data processing. > > Anyway, osrm gives me routes with turns and intersections so this sounds > > to be only a display issue. > > > > > > All the best > > > > François > > > > _______________________________________________ > > OSRM-talk mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/osrm-talk > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20180327/4c42bfb9/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk > > > ------------------------------ > > End of OSRM-talk Digest, Vol 63, Issue 11 > ***************************************** > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk >
_______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
