On -10/01/37 20:59, Peter Körner wrote:
but renderd had a hard limit of 1000 tiles in the queue.
For completeness sake, I thought I'd mention that you can change that
limit quite easily. Simply change the constant at
http://trac.openstreetmap.org/browser/applications/utils/mod_tile/render_config.h#L73
to a higher value and you should be done (well OK, the constant the line
below also should be adjusted).
That limit used to be there, I think, as the queue used a linear list,
which meant adding and searching tiles where O(n), thus n was limited.
It now uses a hashtable lookup, so that limit could be much higher
without problems.
On the main OSM tile server, I believe, that limit is still there as a
feature rather than a bug. In order to achieve a fast turn around time
for mappers, the queue is limited, thus also "limiting" the time a
request takes to get through the queue. Instead requests are dropped
completely and the next time someone views the tile, mod_tile again
tries to queue it. This has the advantage that frequently viewed tiles
are more likely to end up in the queue and then are quickly rendered.
Ideally, you would probably have a large priority queue with the
priority boosted every time another request comes in for that tile. But
that isn't implemented. Does tirex support that?
Kai
P.S. Personally, I think the trade off of 1000 metatiles is somewhat too
low, as with 3 - 5 metatiles / s that yevaud manages, the queue's turn
around time is usually less than 10 - 20 minutes (if it only renders
queued tiles and not on the fly, it is more like only 5 minutes),
whereas the dropped render request means that some of the less
frequently viewed areas might be quite out of date or inconsistent.
However, as with all heuristics and trade-offs, it is hard to judge were
the actual sweet spot is, and it is not really possible to measure it
either. So 1000 metatiles might well be a good compromise. Also on
servers, that can't keep up with rendering demand, even at low traffic
times during the night, that limit is likely to be particularly
important to prioritise.
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
