[OSM-dev] Alternative tile webserver needed?

[Nick Hill]

Hello Dirk

Dirk-Lüder Kreie wrote:

> While it were possible to limit re-renderig of tiles (ie. don't render a
> tile if it has been rendered in the past X hours) but I'd rather not go
> down that path.

> If it helps I can donate a second 160 GB IDE drive to help spread the
> load out over several disks (ie. put the maplint layer on there).

Thank you for the offer. I will be visiting the servers hopefully in the first 
half of next week. (I seem to have isolated a glitch problem in tests on the new 
DB server).

WRT updating tiles, there seems to be a problem which can be characterised as a 
mathematical problem.

We have a very large data set and we are updating very small fragments of that 
data set seemingly randomly. Assuming we can't find non-random elements to 
leverage secondary level storage (RAM), we are limited by the random access seek 
performance of the mass-storage medium.

Using a low latency (expensive) SCSI disk could increase seek throughput by a 
factor of 3-4.

Adding another drive to spread the load will initially improve throughput by a 
factor of 2. But to improve by another factor, we need 4, then 8, 16, 32. 
Quickly becomes unworkable. However, adding drives does usefully increase 
storage capacity, but negatively impacts system reliability. I'd suggest between 
4 and 8 drives is a sweet spot for T at H.

Does the current T at H determine in advance of scheduling a tile to be rendered, 
whether it has been dirtied since last rendered? An index to a list of 32 bit 
INT checksums can be usefully cached in RAM, thereby skipping clean tiles in 
microseconds.