[mapserver-users] Getcapabilities extremely slow in version 6.4.1

[Jim Klassen]

I work with a mapfile designed to be a WMS proxy to organize all our WMS
sources (typically other mapfiles) into one point of access.  It has
many layers makes extensive use of groups.  In general testing with curl
and use with QGIS, I have not noticed the GetCapabilites (or any other
aspect of the configuration) to be slow.  I am away from the machine at
the moment, but will run benchmarks tomorrow.

The upstream sources and the proxy mapfile run under MapServer 6.4.1
(with some minimal patching).

On 03/05/2015 12:33 PM, thomas bonfort wrote:
> IIRC, this happened when we introduced advanced layer groupings along with
> inspire support in 6.2, and has to do with multiple passes through layers
> to determine which ones to activate or not. I'd suspect the cost is
> proportional to nlayers² which is why it comes up for folks with many
> layers in their mapfiles.
>
> Thomas.
> On Mar 5, 2015 7:26 PM, "Lime, Steve D (MNIT)" <Steve.Lime at state.mn.us>
> wrote:
>
>> This is something I’d really like to see fixed. Any chance a test mapfile
>> could be developed and attached to a new ticket on github? Ideally I'd
>> start against 7.0 and then back-port if possible.
>>
>> Steve
>>
>> -----Original Message-----
>> From: mapserver-users-bounces at lists.osgeo.org [mailto:
>> mapserver-users-bounces at lists.osgeo.org] On Behalf Of Rahkonen Jukka (MML)
>> Sent: Wednesday, March 04, 2015 2:34 AM
>> To: aabhayas; mapserver-users at lists.osgeo.org
>> Subject: Re: [mapserver-users] Getcapabilities extremely slow in version
>> 6.4.1
>>
>> Hi,
>>
>> I have been wondering also why GetCapabilities response is so slow for us
>> nowadays and I have indeed added lots of groups to some services.
>> +1 from me for having a look at this issue.
>>
>> We just installed 7.0-beta on our test server and GetCapabilities comes
>> slowly from that too. There are about 40 layers in the test service and
>> response time is about 8 seconds.
>>
>> Sometimes I have been wondering if GetCapabilities could be cached and
>> controlled by some new CONFIG key. Cached GetCapabilities could be set to
>> be refreshed for example once per week/day/hour if there is a need to react
>> on changes in the data, and each time after the mapfile has been edited and
>> saved with a new timestamp.
>>
>> -Jukka Rahkonen-
>>
>> aabhayas wrote:
>>
>>> Hi
>>> Following up on my previous post we still want to use “OWS_LAYER_GROUP”
>> in our map files. We have large number of layers in our map file ( nearly
>> 800).
>>
>>> Currently we are in the process of migrating our MapServer 5.4.2
>> environment in to MapServer 6.4.1.
>>
>>> In MapServer 6.4.1 GetCapabilities request takes more than 1 minute
>> compared
>> 5 second in version 5.4.2. This makes the new environment unusable by our
>> clients.
>>
>>> Is there a possibility where someone in the MapServer development team
>> looks in to this and fix this issue.
>>
>>> Thanks
>>
>>
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/Getcapabilities-extremely-slow-in-version-6-4-1-tp5189325p5191328.html
>> Sent from the Mapserver - User mailing list archive at Nabble.com.
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20150305/da31304c/attachment.html>