That's a good point, thanks. But from a User Experience point of view - getting lots of tiles returned in 2's within milliseconds is better than waiting 10 seconds and then getting a whole bunch of tiles which, once generated, the user has a better experience panning around - until they reach another new area to render tiles.
The experience is rather like WMS vs TMS where you frequently see a blank map area in WMS. Bearing in mind I am using NUM_THREADS = 32 which means there are more processors to deal with the higher number of Metatile(2) requests. Jason On Thu, Jan 12, 2012 at 2:56 PM, Frederik Ramm <frede...@remote.org> wrote: > Hi, > > > On 01/12/12 14:32, Jason Lee wrote: > >> I am focusing and playing around with the METATILE parameter and get >> performance of 1 tile request :- >> >> METATILE(16) - 10 secs >> METATILE(8) - 3.5 secs >> METATILE(4) - 1.5 secs >> METATILE(2) - 0.6 secs >> > > Maybe you are misunderstanding what this means. This means effectively > > METATILE(16) - 10 secs - 256 tiles - 0.039 sec per tile > METATILE(8) - 3.5 secs - 64 tiles - 0.054 sec per tile > METATILE(4) - 1.5 secs - 16 tiles - 0.094 sec per tile > METATILE(2) - 0.6 secs - 4 tiles - 0.150 sec per tile > > > So it seems the best performance for rendering a NEW TILE is to use the >> minimum metatile size of 2 (default is 8). >> > > This is true if you want to render *one tile only*. If however you have an > user behind an OpenLayers client who is likely to requires several > neighbouring tiles, or if you intend to render a large area anyway, then > the larger METATILE numbers give you much better performance. > > Bye > Frederik > > > ______________________________**_________________ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.**org/listinfo/dev<http://lists.openstreetmap.org/listinfo/dev> >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
