Reporter: BenBE1987[at]gmx.net
[Submitted to the original trac issue database at 5.53pm, Monday, 25th April 2011]

While having a look at the list of open requests I saw that there are some requests that are more than two months old. Having a closer look at those tiles I saw furthermore that most of them weren't all them complex either. This suggests that the queue is basically some heap which is known to not work that well in regards to guaranteeing any deadline for the processing.

Wouldn't it be much better if instead of simply throwing things on a heap if the tile selection algorithm for selecting which tileset to render would take aging of requests into account, gradually increasing their priority?

Some simple way to do this would be something like:

RenderPrio = BasePrio * log_A(1+Age)/log_B(Complexity)

BasePrio in this case is 1 for aged tiles (tiles that are older than e.g. 2 months), 2 for render requests due to changes to the map and 3 for manual requests

Age is the Age of the request in seconds.

Complexity is the tile's complexity as shown by the client.

A is some integer base for weighting the age in the priority, suggested values would be between 2 and 8.

B is some integer base for weighting the complexity in the priority, suggested values would be between 10 and 16.

Higher render priorities should be preferred