Hi all,
Am 08.09.2011, 17:18 Uhr, schrieb Tim Alder <tim.alder(a)s2002.tu-chemnitz.de>de>:
The rendering performance correlate very good with the
queue length.
Do you mean this graph:
http://munin.toolserver.org/OSM/ptolemy/tirex_status_queued_requests.html
I found now the parameter
-num in tirex-batch to limit the queue length. I will restart the
process for tiles with z>0.25 and limit the queue to a value of around
5.000.
I fail to see the point (sorry for my tone being provocative, I
really don't intend to be rude). Currently the only effect I have
is: my changes are not being rendered. This is probably because the
queue is not respecting a first-come-first-served order, otherwise
the max-tile age would not be so high. And because of this I can
see no difference if my changes are not rendered because there are
constantly 5000 or growing 558879 (as of now) in the queue.
How about limiting it to *1* (or maybe 2) in order to give other
tiles a chance, too?
Why do you fill the queue quicker than it can be rendered? Just
adding a delay to slow it down would not harm, would it?
Sorry for whining, I just want *some* tiles rendered! :-)))
(And no, it has nothing to do with the replag being horrible, too
http://munin.toolserver.org/OSM/ptolemy/replication_delay2.html)
The real solution would of course to fill a separate queue (back-
ground) with the automatic rerendering and give missing and dirty
tiles a higher priority. And manually dirty marked tiles should
be the same priority as missing, btw...
Greetings,
Kay