[OSM-dev] mod_tile performance enhancements?

Jason Lee jaslee.st at gmail.com
Thu Jan 12 16:18:02 GMT 2012


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 <frederik at 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 at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/dev<http://lists.openstreetmap.org/listinfo/dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120112/bafc2e63/attachment.html>


More information about the dev mailing list