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