> So I would be curious to know if and how much moving over to
> a c based program e.g.[1] using utime would help. I don't currently have
> the possibility to benchmark this on a full planet, but perhaps we can
> test these two options on the toolserver once the rendering stack is set
> up.
I think this is what the Toolserver is for.

>>> Presumably ptolemy is
>>> running a different filesystem, so the latter might behave quite
>>> differently. At first we can just touch the global planet-import
>>> timestamp though every couple of days expiring all tiles at once while
>>> we get everything else running reliably. I suspect there are still
>>> some optimizations possible that might be sufficient, but we will need
>>> to see what performance is like on ptolemy first.
>> Yay, we'll to this. Maybe it would be enough to touch the lower 4 or 5
>> zoom levels on a per-minute or per-5-minute basis and leave the rest for
>> a weekly expire-all event.
>
> Do you mean high zoom (e.g. zoom level 12 - 18) or low zoom (z 0 - z 6)?
> It seems more reasonable to expire the high zoom levels, as on those
> changes are more visible and they are much faster to render, as they
> contain less data.
This is what i tried to say.

 > On the osm tile server, currently, low zoom tiles
> don't get expired at all, other than through a full reimport, so these
> can be months out of date.I wouldn't go as far as that, but rerendering
> low zoom tiles once a week in the background (e.g. with render_list)
> would probably be sufficient.
Once a week is okay, but we'll have to keep in mind that localisation of 
countries, islands, cities an co. are still a major task that massively 
affects the low (0-6) Zoomlevels.

Peter

_______________________________________________
Maps-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/maps-l

Reply via email to