Hi all, Am 08.09.2011, 17:18 Uhr, schrieb Tim Alder <[email protected]>:
> 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 _______________________________________________ Maps-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/maps-l
