[OSM-dev] mod_tile performance enhancements?
jaslee.st at gmail.com
Wed Jan 11 14:09:11 GMT 2012
I think the server is on RAID 1 mirrored.
Actually, I tried isolating the other Layers and benchmarking again. It
turns out the 1st Layer (Polygons) I tried is the most complex which is why
the response time was roughly the same. I tried a Point layer and render
time was about 2 seconds.
I have also played around with METATILE(16) to METATILE(4) in
"render_config.h", recompiled and the time has now gone down from 10 secs
to 1.5 secs, which is much more acceptable..
On Wed, Jan 11, 2012 at 11:23 AM, Simon Poole <simon at poole.ch> wrote:
> What disk configuration do you have?
> PS CLEANMAP (unannonced global version) runs essentially on a very similar
> system, less memory, and doesn't need 10s for a high zoom tile
> Am 11.01.2012 11:39, schrieb Jason Lee:
> I have mod_tile running on a dedicated Linux server (Ubuntu 11.04, 24GB
> RAM, 8 virtual QuadCore i7 processors) and generating some custom maps. I
> am using ab (Apache Bench) to benchmark its performance when rendering new
> tiles (at zooms 17-18, 1 concurrent x 1 run, clearing cache each time) and
> getting time around 10,000 ms (10 secs) per tile. Thereafter it is very
> quick (100ms) because it is cached.
> Ten seconds does sound quite slow and I was wondering what can be done
> to improve it. Just out of curiosity, I tried disabling all the 7 Layers
> except for 1 Layer in the Mapnik stylesheet, so the rendering requires a
> lot less db querying and map rendering - but I'm still getting 10 seconds
> performance. This would suggest that the performance bottleneck is not
> related to the mapnik backend.
> I've also played around with increasing the NUM_THREADS=3 to 32 in the
> renderd.conf, but still no significant performance improvement when
> rendering a fresh tile. Any ideas or pointers would be welcome. Thanks
> dev mailing listdev at openstreetmap.orghttp://lists.openstreetmap.org/listinfo/dev
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev