[OSRM-talk] Subject: Re: Suggested hardware specs for server under heavy use via Digest
Patrick Niklaus
patrick.niklaus at student.kit.edu
Thu Mar 29 09:35:46 UTC 2018
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 <tariq.baig at ds.mpg.de> 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: tariq.baig at ds.mpg.de
>
> Web: www.ds.mpg.de, ecobus.fokos.info
>
> ________________________________________
> From: osrm-talk-request at openstreetmap.org [
> osrm-talk-request at openstreetmap.org]
> Sent: Wednesday, March 28, 2018 2:00 PM
> To: osrm-talk at openstreetmap.org
> Subject: OSRM-talk Digest, Vol 63, Issue 11
>
> Send OSRM-talk mailing list submissions to
> osrm-talk at openstreetmap.org
>
> 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
> osrm-talk-request at openstreetmap.org
>
> You can reach the person managing the list at
> osrm-talk-owner at openstreetmap.org
>
> 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" <tariq.baig at ds.mpg.de>
> To: "osrm-talk at openstreetmap.org" <osrm-talk at openstreetmap.org>
> Subject: [OSRM-talk] Suggested hardware specs for server under heavy
> use
> Message-ID:
> <350C9BAAF4E5894AA7907627B5508828D532F4E8 at 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: tariq.baig at ds.mpg.de
>
> Web: www.ds.mpg.de, ecobus.fokos.info
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 27 Mar 2018 14:41:18 +0000
> From: Patrick Niklaus <patrick.niklaus at student.kit.edu>
> To: Mailing list to discuss Project OSRM <osrm-talk at openstreetmap.org>
> Subject: Re: [OSRM-talk] Suggested hardware specs for server under
> heavy use
> Message-ID:
> <
> CAFxP+1P1OFr6_ea6pcVifLau8pJqp5f4V4KWAdZ9gfno-gQ8Bw at 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 <tariq.baig at ds.mpg.de>
> 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: tariq.baig at ds.mpg.de
> >
> > Web: www.ds.mpg.de, ecobus.fokos.info
> >
> > _______________________________________________
> > OSRM-talk mailing list
> > OSRM-talk at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 27 Mar 2018 08:10:20 -0700
> From: Daniel Patterson <daniel at mapbox.com>
> To: Mailing list to discuss Project OSRM <osrm-talk at openstreetmap.org>
> Subject: Re: [OSRM-talk] OSRM 5.14.3 set kilometers long ways as small
> elements
> Message-ID:
> <
> CANvddSK075Y44OcGTMXu8bqdCW1aj62HPgjHULG3pZe+wRGM9Q at 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 <
> fl.infosreseaux at gmail.com
> > wrote:
>
> > Hi Daniel,
> >
> > 2018-03-26 19:48 GMT+02:00 Daniel Patterson <daniel at mapbox.com>:
> >
> >> 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
> > OSRM-talk at openstreetmap.org
> > 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
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
> ------------------------------
>
> End of OSRM-talk Digest, Vol 63, Issue 11
> *****************************************
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20180329/7baccccf/attachment-0001.html>
More information about the OSRM-talk
mailing list