[OSM-dev] API down?
nick at nickhill.co.uk
Wed Sep 6 00:07:39 BST 2006
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
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