[OSM-dev] Tile generation performance

Tom Carden tom at tom-carden.co.uk
Mon Jul 24 15:08:12 BST 2006


On 20/07/06, Lars Aronsson <lars at aronsson.se> wrote:
>
> So how can we find out what part of tile generation takes these
> two seconds?  Is it some unnecessary initialization that is called
> over and over again, for every new tile?  Does it do a DNS lookup
> that fails and times out after 1.7 seconds, after which it
> continues to do the real work?  Or does any of the SQL calls by
> accident cause a full table scan instead of using an index?  Is
> there a hidden sleep() call?
>

I'd like to highlight Lars' email from last week.  Profiling the tile
generation seems like low-hanging fruit to me.

A tile request currently looks something like this:

http://tile.openstreetmap.org/ruby/wmsmod.rbx?width=256&height=128&bbox=-180,0,0,66.51326044311184&zoom=0

Looking at http://trac.openstreetmap.org/browser/tile.openstreetmap.org/ruby/wmsmod.rbx
we can see what gets triggered.

We can see it calls something like:

http://landsat.openstreetmap.org:3128/wms.cgi?request=GetMap&layers=modis,global_mosaic&styles=&srs=EPSG:4326&format=image/jpeg&width=256&height=128&bbox=-180,0,0,66.51326044311184
http://tile.openstreetmap.org:81/ruby/gpx.rbx?width=256&height=128&bbox=-180,0,0,66.51326044311184
http://tile.openstreetmap.org:80/ruby/renderer.rb?width=256&height=128&bbox=-180,0,0,66.51326044311184
http://tile.openstreetmap.org:80/srtm.php?width=256&height=128&bbox=-180,0,0,66.51326044311184

Lars - maybe try benchmarking those individually (with your more
meaningful width/height/bbox values)?  Although I think
landsat.openstreetmap might only accept connections from
tile.openstreetmap?

Steve, could we set up a copy of that which doesn't actually grab
images, and see if it replies noticably quicker than wmsmod.rbx?

I'm also wondering if the ruby http request thing will do concurrent
requests to the same server by default - worth checking?

If anyone else wants to pick up the chain for the four layer calls,
that would be useful.

Tom.




More information about the dev mailing list