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? >> - 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 >> 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. >> - 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 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. 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? Udo _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
