On 02/15/2010 08:17 AM, Peter Körner wrote:
Yes, i already adopted it for out
multi-style-environment on cassini and
placed it at , but on cassini it was very slow with this much styles.
Do you know what the bottle neck was? Was it DB access to generate the
list of tiles, cpu speed running the ruby script, or filesystem
performance to touch a huge number of files?
I guess it was the filesystem,
because the script only queries the DB
once, no matter how much styles you'll expire.
Even on yevaud, the osm-tile server, that only has a single style, the
tile expiry might be causing some issues. Although not definite, the
high system (rather than user) load seen on that server during "editing
rush-hour" (i.e. when a lot of tiles need expiring), is probably caused
by those scripts. The combination of using ruby and spawning an external
program (touch) for each expired tile doesn't directly strike me as
efficient. So I would be curious to know if and how much moving over to
a c based program e.g. 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.
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. 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.