[OSM-dev] Tirex - a renderd alternative

Stefan de Konink stefan at konink.de
Tue Mar 9 16:30:14 GMT 2010


Op 09-03-10 17:19, Frederik Ramm schreef:
> I agree that distributed rendering is something that must be supported.
> There are several ways to do it; either run a classic load balancer
> setup with some intelligence so that it requests odd tiles from one
> server and even tiles from another etc., or build a mesh of queue
> managers that are aware of each other, or have one master queue manager
> (a.k.a. single point of failure) distributing requests across a range of
> render servers.

I currently have a webserver that does this for me.


> If you were to attempt the latter, I would recommend a messaging deamon
> that takes UDP requests and transports them to the other side using TCP.
> That would allow you to have a steady TCP connection and monitor it
> properly. For localhost use, we decided against TCP because creating a
> new connection everytime you need one is too expensive, and re-using the
> existing one causes too much trouble.

If I would go into this direction I would go by multicast such as mDNS, 
and make render clients bid for rendering the requests. More flexible 
approach. And gives guarantees someone picks it up.


> In theory, Tirex could also be expanded to use multiple messaging
> schemes, just as it uses UDP and Unix domain sockets (for backward
> compatibility) now.

I already like it that it is decoupled from the webserver itself. The 
only thing that has to be taken into account with an 'cgi' approach is 
the fork cost. But personally... I think with a small script that only 
shoots in the coordinates in a packet, that is good enough for anyone 
that doesn't want to write 25 lines of C.


Stefan




More information about the dev mailing list