Hi Johan!<br><br>Can you try to find out if your mapproxy setup is cpu or disk bound using systat utilities?<br><br>Cpu monitoring: mpstat -P ALL 2 <br>I/O monitoring: iostat -xhm 2<br><br>If your mapproxy configuration is set up well the limiting factor should be disk I/O. If you don't see high disk I/O utilization and only one cpu utilized something is wrong with you WSGI configuration.<br>
<br><br>cu andreas<br><br><br><div class="gmail_quote">2011/4/11 Johan Sandberg <span dir="ltr"><<a href="mailto:johs@kth.se">johs@kth.se</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I am performing tests with the software LoadUI. I have pregenerated URLS from a listw which the programe reads.<br>
The backend WMS are a geoserver which is pretty fast. MapProxy is installed on a linux computer running on apache2 with the WGSImode.<br>
<br>
The test scenario are: 400*300, 800*600,1200*900 and 1600*1200 for 10 concurrent users.<br>
Then test the 800*600 for 20,50 and 100 concurrent users.<br>
<br>
I test two different cases when the cache is seeded and when its dynamically filled.<br>
<br>
The results (avarage time milliseconds) on directly to WMS and to seeded cache are as follows<br>
<br>
WMS 400*300 10 request/sec 1157,276546<br>
WMS 800*600 10 request/sec 2027,072179<br>
WMS 1200*900 10 request/sec 3463,510585<br>
WMS 1600*1200 10 request/sec 5571,929988<br>
WMS 800*600 20 request/sec 4045,260605<br>
WMS 800*600 50 request/sec 10349,9973<br>
WMS 800*600 100 requst/sec 20279,21129<br>
<br>
<br>
MapProxy 400*300 10 request/sec 229,7247875<br>
MapProxy 800*600 10 request/sec 1322,603837<br>
MapProxy 1200*900 10 request/sec 2753,405889<br>
MapProxy 1600*1200 10 request/sec 6793,848616<br>
MapProxy 800*600 20 request/sec 2678,599481<br>
MapProxy 800*600 50 request/sec 6545,8422<br>
MapProxy 800*600 100 request/sec 19226,09422<br>
<br>
For the fourth test (1600*1200) the WMS the avarage time is better for WMS than for MapProxy.<br>
The tests are fetching the same data which are severall vector layers compose as one Map layer.<br>
<div class="im"><br>
/ johan<br>
<br>
________________________________________<br>
Från: Rahkonen Jukka [<a href="mailto:Jukka.Rahkonen@mmmtike.fi">Jukka.Rahkonen@mmmtike.fi</a>]<br>
</div>Skickat: den 11 april 2011 13:12<br>
<div><div></div><div class="h5">Till: Johan Sandberg<br>
Kopia: <a href="mailto:mapproxy@lists.osgeo.org">mapproxy@lists.osgeo.org</a><br>
Ämne: Re: [MapProxy] SV: Response time question<br>
<br>
Hi,<br>
<br>
In my tests MapProxy has been either much or very much faster than my backend WMS but that depends on many things. With extremely simple vector layers with simple styles and with just a few concurrent users my WMS can be almost as fast. Biggest speedup (at least ten times faster)is when rendering complicated vector layers like OpenStreetMap data at small scales . Speedup with raster maps or aerial images is something in between, let's say 5 to times faster.<br>
<br>
What is your use case like? What data you have on WMS (vectors/rasters)? I suppose you are testing with WMS calls. Do you use the same projection than your Mapproxy tiles are, or does Mapproxy do reprojection for you? How do you test, are you running the same script with reasonably many requests with jmeter or something?<br>
<br>
WMS can be a bit slow to start, especially Mapserver in CGI mode is such. Therefore it is normal that throughput as bits per second with big WMS requests is higher than with small requests but this depends on the WMS software and also on the data. Mapproxy, on the other hand, is using prerendered tiles of fixed size as a raw material and therefore it is showing a very stable throughput with varying image sizes. With the backend data it is naturally totally ignorant (when serving from the cache), heavy OSM tiles are rendered just as fast as a simple point layer. This is also making it easier to manage the WMS server. It is not so important to use all the tricks I know for making the heavy WMS bulk layers 10 per cent faster because WMS is used just once after each update and thereafter Mapproxy is taking the load.<br>
<br>
Can you give any exact numbers about your tests? How many 400x300 sized images per second you can get out from your WMS and how many through Mapproxy?<br>
<br>
Johan Sandberg wrote:<br>
<br>
> Hej!<br>
> Yes that's offcourse true. This leads to not so greate<br>
> performance on bigger image sizes with Map Proxy.<br>
> Measuring directly to the WMS I see that the scaling is only<br>
> twice the time.<br>
> To a certain image size there is no use of using M.P for<br>
> better perfromance according to the tests I perform.<br>
><br>
> / Johan<br>
> ________________________________________<br>
> Från: Rahkonen Jukka [<a href="mailto:Jukka.Rahkonen@mmmtike.fi">Jukka.Rahkonen@mmmtike.fi</a>]<br>
> Skickat: den 11 april 2011 11:07<br>
> Till: Johan Sandberg<br>
> Kopia: <a href="mailto:mapproxy@lists.osgeo.org">mapproxy@lists.osgeo.org</a><br>
> Ämne: Re: [MapProxy] SV: Response time question<br>
><br>
> Hi,<br>
><br>
> He means that if you'll take four times more pixels<br>
> (800x600=480000 vs 400x300=120000)<br>
> then you'll need approximately four times longer time.<br>
> Rather logical and to my experience pretty accurate approximation.<br>
><br>
> -Jukka Rahkonen-<br>
><br>
><br>
><br>
> Johan Sandberg wrote:<br>
> ><br>
> > Hej!<br>
> ><br>
> > "MapProxy should scale linear with the number of pixels. So<br>
> > you should expect 1/4 requests when changing from 400x300 to<br>
> > 800x600. You should measure the times with one concurrent<br>
> > requests at first and then you should look how you can scale<br>
> > that with increased concurrency, see below."<br>
> ><br>
> > So do you mean that I could expect four times the time to<br>
> > fetch an image that comes from seeded tiles when the<br>
> > requested image size double?<br>
> ><br>
> > Is there any good documenations on this? Would be pretty helpful!<br>
> ><br>
> > / Johan<br>
> ><br>
> ><br>
> > ________________________________________<br>
> > Från: Oliver Tonnhofer [<a href="mailto:olt@omniscale.de">olt@omniscale.de</a>]<br>
> > Skickat: den 31 mars 2011 17:34<br>
> > Till: Johan Sandberg<br>
> > Kopia: <a href="mailto:mapproxy@lists.osgeo.org">mapproxy@lists.osgeo.org</a><br>
> > Ämne: Re: Response time question<br>
> ><br>
> > Hej Johan,<br>
> ><br>
> > On 31.03.2011, at 15:07, Johan Sandberg wrote:<br>
> ><br>
> > > hey!<br>
> > ><br>
> > > I'm measuring responses to Map Proxy when its seeded.<br>
> > > I dont get that satisfying response time as a wish. When I<br>
> > perform requests of a image size of 400*300, 10 request at<br>
> > the time I get low response time(around 50, 60ms).<br>
> > ><br>
> > > When I do image size of 800*600 the response time is up<br>
> to 1-2 sec.<br>
> > > And even bigger image size give response time up to 5-6 sec.<br>
> > > Is this normal response time when requesting seeded tiles?<br>
> ><br>
> > MapProxy should scale linear with the number of pixels. So<br>
> > you should expect 1/4 requests when changing from 400x300 to<br>
> > 800x600. You should measure the times with one concurrent<br>
> > requests at first and then you should look how you can scale<br>
> > that with increased concurrency, see below.<br>
> ><br>
> > > The request should be alligned with the resolution that is<br>
> > seeded so they don't have to re scaled.<br>
> > > How much is the normal cost in time of rescaling an image?<br>
> > Do the request have to be perfectly alligned with the cached<br>
> > resolution to achieve the low response time that I wish?<br>
> ><br>
> > Depends on the resampling method, you have to check for your<br>
> > self. The performance can degrade dramatically when you<br>
> > request a lower resolution than your first/upper level,<br>
> > because it then needs to merge lots of tiles. So make sure<br>
> > you don't run into that.<br>
> ><br>
> > > I have installed map proxy on a Linux computer with httpd<br>
> > apache server. I followed the wgsi example.<br>
> ><br>
> > You should run mod_wsgi with multiple daemon processes when<br>
> > you have more than one CPU:<br>
> > <a href="http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives" target="_blank">http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives</a><br>
> ><br>
> > Regards,<br>
> > Oliver<br>
> ><br>
> > --<br>
> > Oliver Tonnhofer | Omniscale GmbH & Co KG |<br>
> <a href="http://omniscale.de" target="_blank">http://omniscale.de</a><br>
> > <a href="http://mapproxy.org" target="_blank">http://mapproxy.org</a> | <a href="https://bitbucket.org/olt" target="_blank">https://bitbucket.org/olt</a> | @oltonn<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > MapProxy mailing list<br>
> > <a href="mailto:MapProxy@lists.osgeo.org">MapProxy@lists.osgeo.org</a><br>
> > <a href="http://lists.osgeo.org/mailman/listinfo/mapproxy" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapproxy</a><br>
> ><br>
> _______________________________________________<br>
> MapProxy mailing list<br>
> <a href="mailto:MapProxy@lists.osgeo.org">MapProxy@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/mapproxy" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapproxy</a><br>
><br>
_______________________________________________<br>
MapProxy mailing list<br>
<a href="mailto:MapProxy@lists.osgeo.org">MapProxy@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/mapproxy" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapproxy</a><br>
</div></div></blockquote></div><br>