<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Andrea<br>
<br>
Here are csv and jmx files:<br>
<br>
<a class="moz-txt-link-freetext" href="https://dl.dropboxusercontent.com/u/45385184/21781.csv">https://dl.dropboxusercontent.com/u/45385184/21781.csv</a><br>
<a class="moz-txt-link-freetext" href="https://dl.dropboxusercontent.com/u/45385184/qgis_av_21781.jmx">https://dl.dropboxusercontent.com/u/45385184/qgis_av_21781.jmx</a><br>
<br>
>Seeing what kind of requests you made (zoom level and image
size) is going to be interesting.<br>
<br>
Image 1000 x 600 - 1500 x 900, Zoom level 1:800 - 1:5'000. Zoom
level has been selected because most of the cadasdral layers are
visible on that scale.<br>
And yes, image encoding is a very important factor in this
benchmark. However, I think it is a realistic scenario and image
encoding as well as palette generation is indeed a very imortant
thing for a WMS server.<br>
<br>
>however that really turns the benchmark into a png encoding
contest<br>
<br>
In UMN as well as QGIS server, the palette generation for png8 is
implemented as part of the server code (it does not come from a
3rd party lib). So I think comparing that in a benchmark makes
sense. If a test would be driven by rendering speed, you could
also say that the test measures the performance of the underlying
graphic lib.<br>
<br>
In any case, I agree that benchmark results are very specific and
a different test may show a totally different picture.<br>
<br>
Regards,<br>
Marco<br>
<br>
On 25.06.2013 12:01, Andrea Aime wrote:<br>
</div>
<blockquote
cite="mid:CA+nxMTvLrdWqwtESCO1j0oKx2jdyPTKGr-VJjmpyc1qJQAzj8Q@mail.gmail.com"
type="cite">
<div dir="ltr">On Tue, Jun 25, 2013 at 11:13 AM, Marco Hugentobler
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:marco.hugentobler@sourcepole.ch"
target="_blank">marco.hugentobler@sourcepole.ch</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div class="im">>So is Stefan shares the data and
qgis project, can you share the load test itself? I
imagine it's some sort of jmeter thing?<br>
<br>
</div>
Yes, it is basically a copy of the foss4g benchmark
jmeter file, only with layers / styles replaced (and
outputformat is png8).<br>
Sampling extents were generated with python script
from foss4g benchmark.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Can you share it? Or, at least, can you share the
command line used to generate it?</div>
<div>Seeing what kind of requests you made (zoom level and
image size) is going to be interesting.</div>
<div><br>
</div>
<div>I understand the usage of png8 to some extent, however
that really turns the benchmark into a png encoding
contest,</div>
<div>unless rendering is very slow I'd estimate 50-70% of
the time is spent building the palette and encoding the
output</div>
<div>PNG (I took the FOSS4G 2010 benchmarks recently and
made some optimization to GeoServer, now 75% of the</div>
<div>time is spent encoding the PNGs (plain ones, no png8)
if I use the fastest PNG encoder available, and it gets</div>
<div>way worse if I leave it with the standard Java PNG
encoder. Now... imagine adding on the fly palette
computation</div>
<div>on top of that :-)</div>
<div><br>
</div>
<div>Cheers</div>
<div>Andrea</div>
<div> </div>
</div>
-- <br>
<div dir="ltr">
<div>
<div>==</div>
<div>Our support, Your Success! Visit <a
moz-do-not-send="true"
href="http://opensdi.geo-solutions.it" target="_blank">http://opensdi.geo-solutions.it</a>
for more information.</div>
<div>==</div>
</div>
<div><br>
</div>
<div>Ing. Andrea Aime <br>
</div>
<div>@geowolf</div>
<div>Technical Lead</div>
<div><br>
</div>
<div>GeoSolutions S.A.S.</div>
<div>Via Poggio alle Viti 1187</div>
<div>55054 Massarosa (LU)</div>
<div>Italy</div>
<div>phone: +39 0584 962313</div>
<div>fax: +39 0584 1660272</div>
<div>mob: +39 339 8844549</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://www.geo-solutions.it" target="_blank">http://www.geo-solutions.it</a></div>
<div><a moz-do-not-send="true"
href="http://twitter.com/geosolutions_it"
target="_blank">http://twitter.com/geosolutions_it</a></div>
<div><br>
</div>
<div>-------------------------------------------------------</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Benchmarking mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Benchmarking@lists.osgeo.org">Benchmarking@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/benchmarking">http://lists.osgeo.org/mailman/listinfo/benchmarking</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a class="moz-txt-link-abbreviated" href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a class="moz-txt-link-freetext" href="http://www.sourcepole.ch">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
</body>
</html>