[MapProxy] GetCapabilities-request very slow

[Keith Moss]

We've noticed this issue too, albeit with slighty more layers - ~1,600!

Here are the timings:

25 Layers:   30s. Memory usage from 566MB - 566MB (seemingly no increase)
50 layers:     60s. 551MB - 564MB
100 Layers: 120s. 363MB - 395MB
200 Layers: 280s. 395MB - 548MB

I got tired of waiting at this point and gave up :)

I've attached the two configuration files for the 25 layers example.

The long wait only occurs the first time you load the capabilities, after that it returns in < 1s. So I'm guessing you've got some caching going on somewhere?

Cheers,

Keith

__________________________________
Keith Moss
Satellite Remote Sensing Services
Operations
Landgate
65 Brockway Road, FLOREAT WA 6014
PO Box 741 Wembley WA 6913
Ph. (08) 9387 0332 | Fx. (08) 9383 7142
keith.moss at landgate.wa.gov.au
http://www.landgate.wa.gov.au/

________________________________________
From: mapproxy-bounces at lists.osgeo.org [mapproxy-bounces at lists.osgeo.org] on behalf of Oliver Tonnhofer [olt at omniscale.de]
Sent: Friday, 8 March 2013 6:51 PM
To: Max Stephan
Cc: mapproxy at lists.osgeo.org
Subject: Re: [MapProxy] GetCapabilities-request very slow

On 07.03.2013, at 16:06, Max Stephan wrote:
> Every time we are requesting the WMS-capabilities of one of the instances the CPU-load goes up to 100% and the processing-time for the request is up to a minute, in some cases it even exceeds this and no response is returned at all. The servers have up to 600 layers but Geoserver for example doesn´t have a problem handling this number of layers.
> Therefore our question is how we could improve this performance and if this is normal behavior. You can check http://131.220.109.10/proxy/ for the list of instances we are running (1 has only a few layers, 2 a bit more and 4 is the one with >600 layers).

600 layers, that's quite a bit :)

The capabilities are generated by tempita, a simple templating library that is small and easy to embed, but not as fast as other templating libraries. I guess that this is your bottleneck.
Can you make the configuration available and can you time a capabilities request with a service of 100 and 200 layers?


Regards,
Oliver

--
Oliver Tonnhofer    | Omniscale GmbH & Co KG    | http://omniscale.com
http://mapproxy.org | https://github.com/olt    | @oltonn







_______________________________________________
MapProxy mailing list
MapProxy at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapproxy
This e-mail and any files transmitted with it are intended only for the use of the addressee(s). It may contain information that is confidential and privileged, in which case neither is intended to be waived or lost by mistaken delivery to you. If you are not an intended recipient, any use, interference with, disclosure, distribution or copying of this material is unauthorised and prohibited. If you receive this e-mail in error, please notify the sender by return e-mail and delete the message and any attachments from your system. Unless specifically indicated, this e-mail does not constitute formal advice or commitment by the sender or the Western Australian Land Information Authority (Landgate). Information in this message not relating to the official business of Landgate shall be understood as neither given nor endorsed by it. It is your responsibility to check any attachments for viruses and defects before opening or sending them on. Landgate’s liability is limited to re-supplying affected attachments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: base-mapproxy.yaml
Type: application/octet-stream
Size: 2354 bytes
Desc: base-mapproxy.yaml
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20130313/95d2e0f4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firewatch.yaml
Type: application/octet-stream
Size: 9770 bytes
Desc: firewatch.yaml
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20130313/95d2e0f4/attachment-0001.obj>