request doesn't fit into a rendering queue
RenderPrio, Render and RenderLow queues each only have a size of 32 entries. If these are full,
then requests overflow into the dirty queue. If this happens, renderd should send the NotDone
back immediately so that mod_tile doesn't wait for potentially a long time.
This however only worked for Render requests, but not RenderPrio or RenderLow. This patch fixes this.
* Only treat OPTIONS as preflight if Access-Control-Request-Method is set
* Only send Access-Control-Allow-Headers for preflight requests
* Don't send a bogus Access-Control-Allow-Headers value
This likely needs more improvements to make the readme actually useful.
But for now this mostly removes parts of the readme that were totally
out of date and confusing.
sets the new MaxLoadMissing to 50 and MaxLoadOld to 16.
With the prevalence of multi core servers today, the previous
default thresholds of 10 and 5 were becoming to lower than the average
CPU count. Furthermore, load is not an ideal measure, as it includes I/O
load and much of the I/O load might well come from serving rather than
rendering. Especially if the database is on a separate SSD. Lastly, using
the thresholds in mod_tile isn't super helpful, as due to hysteresis of
rendering queues stop submitting tiles at a time of high load is not
particularly helpful without stopping rendering from the queue.
In addition to Render and RenderPrio, add another priority level of RenderLow.
The idea is that if you rerender all tiles by touching planet-import-complete and
thereby likely overloading the server's rendering capacity you want to prioritize rerendering
of tiles that were explicitly marked dirty due to data changes over rerendering
due to planet-import-complete updates.
This is achieved by splitting rendering requests by if they are "old", or "very old".
As the tile expiry sets back the modification date many years, mod_tile splits
rendering requests based on how old the tiles are. If they are no more than a
certain threshold (currently set to one year) old, they are rendered with lower priority.
The default postgresql connection pool size of mapnik is 10, which can get exhausted
on modern multi-core servers.
This sets the max_size parameter to 2 larger than the thread count unless it is
explicitly set in the loaded stylesheet.
While mod_tile could handle much higher zoom levels already, renderd was stuck with z18,
unless one changed the compile time setting.
This changes the maximum supported zoom level to z20 out of the box. Furthermore,
it is now possible to set max and min zoom level per style in renderd.conf (as long
as they are within the range.)
Zoom levels higher than z20 are currently not supported out of the box, especially with
the file based storage backend. The directory hash function only supports 40 bit (20 bit for each X and Y).
It assumes that one doesn't set an explicity buffer_size of 0 and thus
all buffer_sizes are the default for which renderd then overwrites it to
buffer_size 128.
Addresses issue #17
Apache's memory pool operations aren't thread-safe. In get_storage_backend
multiple threads could try to allocate memory on the process pool concurrently
leading to segfaults. To prevent this, wrap that code into a mutex.
Benchmarking seems to indicate, that even though each request has to acquire the lock
this does not appear to have a performance impact.
The issue was reported by Sven Geggus, and diagnosed by Tom Hughes. Thanks.
