[OSM-dev] Questions/Ideas/Plans on OSM Infrastructure

Dominik Bay eimann at etherkiller.de
Thu Sep 17 13:45:58 BST 2009


Kai Krueger schrieb:
> On 22/07/28164 20:59, Dominik Bay wrote:
>> Hi all,
>>
>> I'm coming up with a topic for discussion on how to save and
>> serve OSM data for Slippy Maps, Mobile Devices and handling
>> routing-requests.
> 
> I am not entirely sure what you are trying to achieve with this topic
> and who you are targeting with it (Osm sysadmin? potential donors? The
> community and what they want from OSM, or are you planning on donating
> Hardware your self?), but I will try and comment on some of the points
> about the rendering.

Mainly OSM Admins/Developers on planned features, resolving bottlenecks
and in the end donating/setting up additional infrastructure for it.

>> ====
>>
>> 2. Why do we need it?
>> ---------------------
>> Due to growing Software based on OpenStreetMap and OpenRouteService
>> we need a more-realtimish behaviour of our data, to serve mobile
>> Users with actual tiles and a fast route calculation.
> 
> Not sure what your definition of "more-realtimish" is, but I would say
> our rendering is already approaching "near realtime" At least the main
> mapnik layer should currently only have a lag of about 5 to 10 minutes
> behind the main OSM database. During load spikes it could be more,
> although with the new render server put in place a week or two ago, we
> haven't really seen any times when the rendering couldn't keep up.
> Furthermore, with the new replication mechanism of diffs, that is
> starting to be tried out, this lag may get reduced even further to about
> a minute.  There is a potential that it feels less realtimish to users
> though due to client side caching. Tile expiry for proxy servers is set
> to something between 3 and 6 hours currently, so if you have visited the
> map before the edits, your browser may still cache the old tiles for
> that duration.  The tiles at home layer I think also aims to achieve
> rendering turn-around times of 10s of minutes to couple of hours, so
> isn't that much behind mapnik either.

Ok, that's something I wasn't aware of. Thanks for pointing out :)


>> We also need to get tiles *fast* to our users, this is why they are
>> called *Slippy* Maps ;-)
>> (They are fast at the moment, thanks for your work on mod_tile, I'm
>> impressed!)
> 
> Yes, the current server can quite happily sustain the full 100Mbs link
> that we currently have available which was demonstrated again the other
> day during the load spike caused by the TV program Quarks and Co.

That's good, so the Backend is already being able to serve many Users ...

> The response time of a single tile should be anywhere between 50ms if
> the tile is currently cached and you have a good connection to where OSM
> is hosted to about 3 seconds, if it tries to render the tile on the fly
> but is too complex to do so and times out to return a slightly older
> cached tile. Which is pretty fast as well.

... but still depends on a low latency to the User who is requesting
tiles. Therefore I am aiming to atleast get that on the same level
anywhere, which does not count in Latency generated by slow links,
packetloss etc. We can't do anything about this problems.

> So at the moment the problem with tile serving, if any, is a question of
> hosting and the increasing bandwidth requirements OSM has. During
> typical daytime tile serving uses about 50 - 60 Mbs sustained with night
> time dropping to 10Mbs. (Tiles at home and cycle map not included)

Which is not much traffic yet but involves a single point of failure.
If this box dies, no tiles are served. Do you have any ideas of traffic
distribution to US/EU/ASPAC? Serving US out of EU wouldn't be that
efficient (to keep the ~50msec as a standard), so it would be nice to
start with some proxies in the US.

>> 3. A short description of what can be done
>> ------------------------------------------
>> We can make use of things like Anycast and Geo-aware Caching.
>> This means a user connects to a Tile-Proxy which is near his
>> ISP (routing-wise) and holds all tiles which are relevant for
>> the users location (Europe for example) plus the Tiles which
>> are requested often (big Cities).
> 
> Yes, that could theoretically be done, and there have been two
> successful tests in the past with using Wikimedia proxyies. So software
> wise this could presumably be done. Software is not everything though
> and for this to work, you also need the proxy caches and the hosting. So
> again, the issue here as far as I can see it, is hosting. But I am sure,
> if ISPs or datacenters are willing to donate free, reliable hosting with
> 100Mbs - 1000Mbs network links, we could scale up our current tile
> serving quite well. But for the moment, we are limited to the resource
> we currently have.

I'm working on it ;-)
More is coming in the next (two) week(s) I think, so I can give you more
details on specific things.


>> To get a better understanding of the next lines, feel free to open this
>> picture:<http://eimann.etherkiller.de/nmz/osm.png>
>> ->  Rendering
>> ------------
>> The goal is to get nearly-realtime rendering of all map-types and the
>> option to easily do customized rendering for supporting events,
>> Wikpedia, etc.
>> This also enables us to support rendering of 3D Layers with very low
>> delay.
> 
> As I said above, we basically already have near-realtime rendering of
> the standard mapnik layer. Providing customizabile tiles of maps, I
> don't think, should be the core focus of the OpenStreetMap project
> itself. For that I think companies and projects like Cloudmade,
> Geofabrik, or Tiledrawer.com are much better suited which have sprung up
> around the OSM dataset. In my opinion OSM should provide, with respect
> to rendering tiles, a sufficiently high quality map so that the general
> public is attracted to OpenStreetMap which then hopefully lowers the
> barrier of entry to start editing and improving the data. But that goes
> into the political question of what OSM stands for and what it wants to
> offer.

I agree on that, I was just an Idea to present an additional usecase of
the data.

> But why exactly are you putting specs together? Are you planning on
> hosting your own rendering infrastructure or donating hardware to OSM?

Yep I'm currently collecting on things which already have been done, and
what we can improve.
To not just putting a text together I'm also working on getting the
ressources in place to kick off with some stuff end of 2009.

Thanks for your explanations. :)

Best regards,
Dominik




More information about the dev mailing list