[OSM-dev] Improvement of tile rendering
udo.osm at nova-sys.net
Sat Mar 21 10:18:31 GMT 2009
Saturday, March 21, 2009, 10:39:00 AM, you wrote:
>> - in this case a Apache module is probably not really faster than a
>> FastCGI implementation
JB> Maybe, but you need both implementations to do a fair comparison.
JB> Serving the tiles directly from the Apache thread should be faster than
JB> going via the FCGI interface.
I was talking in general. The difference between an Apache module and
FastCGI in terms of speed is minimal in terms of CPU utilization. BTW,
do you know how many requests the OSM server has to serve on a typical
>> - FastCGI would allow you to keep rendering daemon and request
>> handling at one place (in one process)
JB> Splitting the low level request handler from the rendering daemon was a
JB> deliberate design decision. This allows for greater scalability. The
JB> rendering is quite heavyweight and slow, we don't want to burden the
JB> request handling threads with job of doing the rendering.
I'm not crititizing mod_tile, so the design decision is okay. However,
having request handling and rendering in one process allows direct
communication between them. For example, the request handler can
decide (for a uncached tile) wheter to wait for rendering to complete
or respond with a 404 when server load is too high. I understand that
this is also possible in the mod_tile model but you need some sort of
IPC in that case.
>> - FastCGI is more portable, as it is not bound to Apache (consider
JB> When I wrote the current code I was happy to just support Apache. There
JB> is nothing to prevent someone developing an fcgi based mod_tile
Sure, there is nothing wrong with mod_tile, I just replied because you
said that you want to reimplement the mod_tile module with Python.
>> - the FastCGI server runs with it's own system user, which makes file
>> access (caching...) easier
JB> The rendering daemon runs as a non-Apache user too. I don't see much
JB> difference here.
non-apache != a specific user.
That's why most ISPs prefer PHP-FastCGI to mod_php.
JB> I did initially try FastCGI before I opted for a custom module. I just
JB> found the fcgi code I wrote 18 months ago. I can not see why I dropped
JB> this approach but I think I was unhappy with the FCGI_ C interface and
JB> found it easier to work directly with Apache.
The FastCGI C interface is nearly the same as programming a standard
CGI handler, so you just get a bunch of environment variables and
three streams (stdio). High languages usually provide a wrapper for
the FCGI functions so that it becomes really easy. On the other side,
hadling of simple GET requests is really simple to do (5 lines of
In my eyes a FastCGI server is like a dedicated web server, which is
optimized completely for the requests it has to handle. Apache is just
a proxy. I would not want to miss the flexibility it provides, but in
the end it's just a design decision, as you say.
JB> You are right that serving up pre-rendered tiles is the common case that
JB> we need to optimise. Unfortunately storing the plain pngs on the
JB> filesystem has its own scaling problems. This also provides quite
JB> limited abilitiy to http expiry headers and triggering re-rendering of
JB> old tiles.
How does mod_tile cache tiles, then?
More information about the dev