[Tilesathome] t at h server performance

[Martijn van Oosterhout]

On Dec 24, 2007 6:07 AM, D Tucny <d at tucny.com> wrote:
> On 24/12/2007, Martijn van Oosterhout <kleptog at gmail.com> wrote:
> > You need at least three states, (LAND/SEA/TILE) so I'd suggest you
> > look at the code supporting the oceantiles_12.dat file which does
> > exactly this. Not everybody likes it though. An SQL table has the huge
> > advantage of being easily accessable with standard tools...
>
> Do we need the 'tile' state? This is fall back, if a tile is marked as land
> or sea, but we serve a tile from the filesystem, it makes no difference...
> Having a third state doubles our storage requirements...

Actually, I had 4 states :). You see, the blanktile DB has a fallback
machanism also, so you need a state to represent "fall back to
parent". By carefully choosing this to be "00" you can use sparse
files. i.e., the filesize says 2.whatever GB, it won't actually use
all that space. Ofcourse, you need to be on a filesystem that supports
sparse files. This also has the added advantage that you can start
using it without creating all the data first.

However, I still think we're getting ahead of ourselves. Attached is a
patch which I beleive will cut the number of blank tiles created by
clients by between 50 and 80%. I beleive that we can make the DB much
smaller, because the size of the blank tile DB is *independant* of the
size of the OSM database. If we get it right I think the database
should stabilise at a size much smaller than what it is now...

Have a nice day,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lessblanks.patch
Type: text/x-patch
Size: 1807 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20071224/b80108d5/attachment.bin>