[OSM-dev] Renderd problems.
jochen at remote.org
Sat Oct 2 14:48:25 BST 2010
On Sat, Oct 02, 2010 at 01:28:48PM +0100, Kai Krueger wrote:
> 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
> 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?
No, its doesn't. But you could add something like this externally. Have
a process read the log file and count requests and re-queue them with
rising priority and possibly the "only-if-older-than-filter".
It also supports an expire time for queued requests. So you can queue a
metatile and give the request an expire time. If the metatile couldn't be
rendered in time, it will silently drop out of the queue. If a new request
for the same metatile comes in, the expire timer starts anew.
Jochen Topf jochen at remote.org http://www.remote.org/jochen/ +49-721-388298
More information about the dev