That was pretty much the kind of answer I was expecting.<br><br>We will do as you say. Any help/guidance is welcome.<br><br>Thank you all for your contribution.<br><br><div><span class="gmail_quote">2007/7/3, Frederik Ramm <
<a href="mailto:frederik@remote.org">frederik@remote.org</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Andres, Jose -<br><br>
    thank you for your generous offers. tiles@home could really benefit<br>from its own server(s). I had started a thread on the dev list (that was<br>before we had a t@h list) in May about this:<br><br><a href="http://lists.openstreetmap.org/pipermail/dev/2007-May/004958.html">
http://lists.openstreetmap.org/pipermail/dev/2007-May/004958.html</a><br><br>I am really in favour of moving tiles@home completely away from dev, and<br>since the tiles@home server does not access the OSM database, there's
<br>absolutely no need for it to sit where the other servers are.<br><br>If you look at the numbers and the Munin graphs, you'll see that the<br>tiles@home server has to handle a lot of disk and network I/O. I am not<br>
really a hardware expert so I cannot judge if the servers that you are<br>talking about can handle that, and if the network pipe is big enough.<br><br>In a multi-server setup, it would be possible to have one server run the
<br>Mysql database with the tile meta data and process uploads, while a<br>second server (accessing the tile repository in read-only mode) would<br>serve tile download requests. That could provide some breathing space<br>
for the components involved, but on the other hand there's still one<br>place where tiles are stored so if the bottleneck turns out to be<br>writing to and reading from the tile repository then it might not be<br>such a good idea to have separate servers.
<br><br>You are of course free to just get the current PHP source (it is in SVN<br>under sites/other/tilesAtHome or so), install it and play around with<br>it. Modifying the t@h client to upload to your server(s) should be
<br>simple. Some guidance by OJW will perhaps be required as regards pieces<br>of the puzzle that aren't in SVN (like apache config, cron jobs, MySQL<br>structure).<br><br>The final decision on whether and where tiles@home
 is moved lies with<br>the people running "render farms" - you can provide the best server, but<br>if they don't follow, then your server will run empty. And while the<br>people running "render farms" are free to decide how they participate,
<br>they will most likely do what OJW  (Oliver White, creator of tiles@home<br>and current maintainer of the tiles@home server on dev) says. If he says<br>  he's closing down t@h on dev and re-opening it on one of your servers,
<br>then everyone is likely to follow. (Some URLs need to be fixed in the<br>slippy maps out there afterwards but that's the smallest problem.)<br><br>So my advice would be: Analyse the requirements (starting from my<br>
posting above, and looking at the munin graphs etc.), find out whether<br>your servers are likely to outperform the dev server (to a degree that<br>makes a move worthwile), then install the t@h server components for<br>testing, and if it all looks good, then talk to OJW about making the
<br>move. (It would be wise to solicit some opinion from him beforehand.<br>He's sometimes hard to reach, try IRC.)<br><br>Bye<br>Frederik<br><br>--<br>Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org">frederik@remote.org
</a>  ##  N49°00.09' E008°23.33'<br></blockquote></div><br>