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 [1], 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.[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. > > > 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. > > Peter Kai [1] http://trac.openstreetmap.org/browser/applications/utils/mod_tile/render_expired.c _______________________________________________ Maps-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/maps-l
