[OSM-dev] API down?

Nick Hill nick at nickhill.co.uk
Wed Sep 6 00:07:39 BST 2006

Hello Lars

The backup was completed at 01:40 BST on 5th September. No changes were 
made to the database.

The tile server is really buckling. Earlier today, It took 15 seconds to 
do `ls /tmp`

(and /tmp only has around 100 files).

Faster code to render map tiles will help a lot. If we could improve the 
efficiency of tile rendering by an order of magnitude (like we recently 
done for the database) it could then handle demand for the time being.

I would like to see stats of how much processing demand each slippy map 
user puts on tile with the current set-up, and suggestions how we can 
improve the efficiency of tile serving.

Currently, the burden each slippy user puts on tile is unclear. tile 
does lots of things. Once we move the tile rendering off to another 
physical machine, i'll have a better idea of what sort of demands each 
slippy map user puts on tile.

What is the feasibility of transferring rendering load to the client by 
serving slippy tiles as SVG (using something like osmarender)?

It seems people get more frustrated now tile is buckling rather than DB 
buckling. Perhaps we should slow down DB to take the pressure off tile 
(just kidding!)

Lars Aronsson wrote:
> Do we have any logs from which we can compile statistics on how 
> often the tiles get broken?  Or are we acting as if it just 
> doesn't matter?

As it stands, you're lucky to get a whole set of good tiles. It 
certainly does matter, We need code which cures the problems. As it 
stands, I believe better code is the key. We can't just throw more 
hardware at the problem until we know what we can achieve with the extra 
hardware. We will know this when we have the separate tile renderer running.

More information about the dev mailing list