[OSM-dev] Improvement of tile rendering

[Jon Burgess]

On Sat, 2009-03-21 at 11:18 +0100, Udo Giacomozzi wrote:
> Hello Jon,
> 
> 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
> day?

The logs for a fairly typical day show 28M requests:
$ gzip -dc access.log-20090320.gz | wc -l
28211437

http://munin.openstreetmap.org/openstreetmap/tile.openstreetmap-apache_accesses.html

Using "ab" to benchmark the server shows it can do a few thousand
requests per second which would easily saturate the upstream WAN
connection. 

> >> - 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.

I don't see it as a criticism. The mod_tile code does make the decisions
you mention above. Only the rendering is offloaded to the backend
daemon. 

> >> - FastCGI is more portable, as it is not bound to Apache (consider
> >>   Lighttpd)
> 
> 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
> JB> implementation. 
> 
> 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.

Initially I was looking for something which was a drop-in replacement
for the existing code but an alternative implementation using fcgi would
be OK too. I was thinking of just using mod_python which has some of the
benefits of fcgi.

> 
> >> - 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.

I was not intending it mod_tile to be a suitable solution for a shared
hosting environment. I agree that a pure script or fcgi solution may be
better for that. Good luck getting Mapnik installed in this setup.

If you are talking about only serving pre-rendered tiles then again,
mod_tile probably is not the best solution.

> 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).

FGCI_ does some nasty things to redefine printf() etc in an attempt to
hide some of the implementation details. While this is good for some
things, it is not so good when you want fine control. It also does not
allow multithreading. The FCGX interface looks better.

>  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
> code, maybe).
> 
> 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.

Right, I preferred to integrate with Apache instead of integrating with
fcgi.

> 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?

It stores metatiles which are a simple custom archive format storing an
8x8 grid of PNGs in a single file. The rendering creates all 64 tiles at
the same time which is more efficient as well.

	Jon