In addition to the request queue and the dirty queue, there are now also a requestPrio and requestBulk queue.
The rendering order now is first render requests from requestPrio, then from request followed by the
dirty queue and finally if no other requests are queued, render from the requestBulk queue.
RequestPrio, Request and RequestBulk all block, whereas Diry immediately returns with NotDoneYet.
This also changes mod_tile to submit requests that if not rendered in time would result in 404 errors as high priority.
prioBulk should be useful for things like rerendering all the outdated tiles in the background, but this patch
does not include those changes.
When calculating the the intermediate hashkey I incorrectly assumed long was 64 bit. This meant that the hashkey could turn negative
which in turn would cause a segfault on array access.
Thanks to Richard Ive for spotting and debugging this error.
By eliminating the linear look up of the dirtyQueue for every newly added rendering request, it should be possible
to significantly increase the length of the dirty rendering queue. At the moment the queue length is set to 1000 metatiles,
which at a typical rate of 2 - 3 metatiles a seconds is a buffer of only 5 - 10 minutes. With a much longer
queue, the excess daytime requests can be moved into the quieter night time hours, which could improve the overall long-term
throughput if the server is at its limit of what it can handle.
All operations on the dirty queue should now be O(1).
This extends renderd to support TCP/IP sockets in addition to unix sockets for submitting rendering requests
and thus renderd can be on a different server.
Furthermore, to distribute the load across multiple servers, renderd can now also dispatch requests to slave renderd's.
So Mod_tile (or any other program driving renderd) submits all its requests to the master renderd, where the requests get
queued in case there are too many. The master renderd then dispatches requests one at a time to either local rendering threads
or to the slave threads, which ever are free for the next request.
To configure this, you can add multiple [renderdN] sections, where N represents the Nth slave and specifies how many threads
it has, its host name and ip port.
The protocol currently does not pass back the actual tiles, so all renderd's have to be able to write to the same
tile directory (e.g. via NFS)
This patch reports two properties of the served tiles. First it reports how many tiles are returned with which response code, i.e.
how many tiles get return with http code 200, 304, 404 or 500. Secondly, it reports if tiles are returned fresh from disk, fresh
after being rendered on the spot, old without attempting to render, old after timing out waiting for the tile to be rendered.
The stats get reported through a special page at "http://servername/mod_tile".
Caveat: In order to report the stats of a global counter, a mutex is needed that serialises access to that counter. This can have
some performance effects, although it is attempted to hold this lock as short as possible. Measuring the effect with apache bench,
running for 1 million tile requests at a concurrency level of 10, this gave about a slowdown of 1%. This should be pretty much
worst case, as apache bench always requests the same tile, so that is all in cache. With this, it still achieves more than 5800
requests per second at 50Mb/s on a dual core laptop. On different hardware, this can obviously differ.
Stats reporting can be disabled with a config setting in mod_tile.conf
The locking code is based on mod_example_ipc.c
The initialisation of the per zoom level cache expire table was done in the wrong
section of the configuration parsing. This meant the results were order dependent in statements in mod_tile.conf,
as some of the values might not have been correctly set at that time of calculating the table.
- Changed counter type to DERIVE. This supposidly handles counter resets better and thus should be mre robust
- Stacked Request and Dirty queue, to better show the overall renderd throughput
- Rescale the dropped tiles graph by a factor of 20 to make it more similar in magnitude as the rendering to
be able to show both on the same axis. This has some justification,
This allows to monitor the performance of renderd and how well it can keep up with the
render requests that are coming in or if it drops them due to overload.
Achieving a high cache hit ratio is both beneficial to clients and the server. For the clients it is
reduced loading time and for the server reduced resources used. To achieve this, cache expiries should be set
as long as possible. However, this conflicts with wanting up to date tiles, especially with minutely renderings.
As you can't predict the future, one can only use a bunch of heuristics.
With this patch, the tile expiry heuristic is based on three factors. The frequency of planet updates (the heuristic used so far),
the zoom level and the last modified time. The idea behind the zoom level heuristic is that low zoom tiles don't change noticably
very often, and so can use longer cache expiries than high zoom tiles. The last modified heuristic is based on the assumption
that a tile that hasn't changed for a while is more likely to stay unchanged than one that has recently been modified.
The heuristics have a bunch of tunables that can be set in the apache config of mod_tile
For large setups of mod_tile, and renderd, it may be beneficial to have a reverse proxy infront of the main tile server.
However when using a fast updating db e.g. running off the minutly diffs, the proxy may either deliver stale content, or the
cache expiry has to be set very short, which limits the effectiveness of the proxy. Instead, this patch adds an explicit
mechanism to renderd to signal to the proxy which tiles have been rerendered and thus should be discarded from the cache.
* -t|--tile-dir option for render_list and convert_meta
* renderd reads it from renderd.conf section "[renderd]" setting "tile_dir"
* mod_tile reads from Apache conf ModTileTileDir directive
There are still some places in store.c left, where HASH_DIR is used directly. More fixes needed.
Added --map command line option to render_list (name of map config instead of "default")
Added --all command line option to render_list (render all tiles in given zoom levels instead of reading from stdin)
