[mapserver-users] mapcache seed speed optimization

[Sebastiano Laini]

I manage to seed at 300 tiles/s in the less complex layers, now I need to speak with the technical director and see how we are going to optimize our data.

I was trying to test MapProxy but I couldn’t install it in our Centos 7 machine, I may give it a try again.
For your experience which one is the fastest one? Not just seeding but in delivering the requests also.

What tiles size are you using normally? Are you still using HTTP1 or HTTP2?

Regards,

Sebastiano Laini
Web Developer
Buchanan Computing

From: Travis Kirstine [mailto:traviskirstine at gmail.com]
Sent: 11 November 2019 14:42
To: Sebastiano Laini <Sebastiano.Laini at BuchananComputing.co.uk>
Cc: Fawcett, David (MNIT) <david.fawcett at state.mn.us>; Rahkonen Jukka (MML) <jukka.rahkonen at maanmittauslaitos.fi>; mapserver-users at lists.osgeo.org
Subject: Re: [mapserver-users] mapcache seed speed optimization

I may not be unrealistic for it take mapserver to 4-6 seconds to generate 4096px image depending on the amount data being rendered and the complexity of your styles / expressions / labels.  If your mapserver is able to generate a 1024x1024 in under a second that is pretty good.  Like Jukka and other suggest I would look at translating the files to shp files with spatial indexes or postgis tables with spatial and attribute indexes if necessary.  Preprocessing the data (simplification / prefiltering / point thinning cluster) and using SCALETOKENs to reference different source layers at different scales can lead to big performance boosts at the mapserver end.

For us the biggest limiting factor has been the write blocking to sqlite cache when seeding tiles, if you increase the number of threads / process in mapcache seed those process will just end up waiting to write to the cache.  You can generally figure out what the max number of processes the cache can handle by running a seed on a test area and look at the number of tiles seeded per second, as some point -n will have no effect which your process are just waiting to write the cache.  I would look at using this method to test sqlite vs disk or other backends.  The GeoTiff cache may be promising as it appears to be non-blocking but experimental...

We use a riak cache with a riak leveldb backend which works well for us but is a bit of a pain to manage as it difficult to delete objects so it's not great for caches that need to be refreshed.

Finally you may want to test MapProxy as an alternative to MapCache (we use both).  MapProxy supports a non-blocking compact cache that could solve your inode problem

Regards









On Fri, 8 Nov 2019 at 11:48, Sebastiano Laini <Sebastiano.Laini at buchanancomputing.co.uk<mailto:Sebastiano.Laini at buchanancomputing.co.uk>> wrote:
We don’t create the data, we rely on OS (ordnance survey) to supply us the maps files and then we publish them in our service but I assume that probably we will need to create some flow to improve it or download it in other format that is faster.

Sebastiano Laini
Web Developer
Buchanan Computing

From: Fawcett, David (MNIT) [mailto:david.fawcett at state.mn.us<mailto:david.fawcett at state.mn.us>]
Sent: 08 November 2019 16:41
To: Sebastiano Laini <Sebastiano.Laini at BuchananComputing.co.uk<mailto:Sebastiano.Laini at BuchananComputing.co.uk>>; 'Rahkonen Jukka (MML)' <jukka.rahkonen at maanmittauslaitos.fi<mailto:jukka.rahkonen at maanmittauslaitos.fi>>; 'mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>' <mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>>
Subject: RE: mapcache seed speed optimization

For data formats that are slower to read, would it add fit your workflow to convert it to different data format before creating the tiles?
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20191112/91eac1a0/attachment.html>