Thank's for your advices guys.<br>The idea of contributing to tilecache is a highly desirable one, though I'd rather use a LFU algorithm to transfer tiles from RAM to disk, but I'm not (yet) familiar with python. Moreover, delays are small before we must deliver the software ...
<br>Anyway, I think this is a great direction for the next developments of TileCache.<br><br>F.<br><br><div><span class="gmail_quote">2007/3/14, Schuyler Erle <<a href="mailto:sderle@metacarta.com">sderle@metacarta.com
</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Tue, 2007-03-13 at 16:28 +0100, François Van Der Biest wrote:<br><br>> There are 4000 points of interest for which we would like tiles to
<br>> load very quickly.<br>> This is the reason why I suggested to use two cascading tilecache:<br>> - first one on the front machine, with memorycache enabled and a lot<br>> of RAM<br>> - second one on the WMS providing machine (the one with mapserver
<br>> installed) with diskcache enabled and a big fast disk.<br><br>This would probably work fine.<br><br>I agree with Chris Holmes that a small amount of work in Python would<br>get you a single layered Cache inside TileCache, and this would probably
<br>be more reliable than running two separate instances -- but you want<br>them on separate machines, which is probably sensible.<br><br>Before you go there, though, have you tried stress testing the disk<br>cache by itself on your hardware? You may find it runs fast enough (or
<br>nearly fast enough).<br><br>SDE<br><br></blockquote></div><br>