<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Andrea,</p>
<p>Thanks a lot for this additional information. How many new
connections are established in your scenario? I.e. can this be
introduced by the additional roundtrips for handshake?</p>
<p><br>
</p>
<p>I just tried to reproduce this on QGIS here. And in my scenario I
could not find any evidence for a performance impact. Without SSL
I got 110 seconds, with SSL I got 108 seconds (100 iterations). So
even more performance (probably not on a statistically relevant
level).<br>
</p>
<p>The only thing I can think of that I didn't measure in my tests
were roundtrips (because the server was run locally).</p>
<p>I would like to raise this topic on stackexchange or the postgres
mailing list to get some more insights. But it would be much
easier to argue if I could provide a real world example of
degraded performance.<br>
</p>
<p><br>
</p>
<p>Scenario:</p>
<p> Docker container from the QGIS tests
(<a class="moz-txt-link-freetext" href="https://github.com/qgis/QGIS/blob/master/.ci/travis/linux/docker-compose.travis.yml">https://github.com/qgis/QGIS/blob/master/.ci/travis/linux/docker-compose.travis.yml</a>)</p>
<p> docker-compose -f .ci/travis/linux/docker-compose.travis.yml up
--build postgres</p>
<p> # wget
<a class="moz-txt-link-freetext" href="https://github.com/QGEP/datamodel/releases/download/1.3.0/qgep_v1.3.0_structure_and_demo_data.backup">https://github.com/QGEP/datamodel/releases/download/1.3.0/qgep_v1.3.0_structure_and_demo_data.backup</a></p>
<p> pg_restore -U docker -d gis -h 172.19.0.2 -1
qgep_v1.3.0_structure_and_demo_data.backup<br>
</p>
<p> Restart QGIS with ~/.pg_service.conf with</p>
<p> - `sslmode=require`</p>
<p> - `sslmode=disabled` <br>
</p>
<p> Running the following snippet</p>
<pre style="background-color:#2b2b2b;color:#a9b7c6;font-family:'DejaVu Sans Mono';font-size:9.0pt;"><span style="color:#cc7832;">import </span>timeit
<span style="color:#cc7832;">def </span><span style="color:#ffc66d;">get_features</span>():
<span style="color:#cc7832;">for </span><span style="color:#808080;">f </span><span style="color:#cc7832;">in </span>iface.activeLayer().getFeatures():
<span style="color:#cc7832;">pass
</span><span style="color:#cc7832;">
</span><span style="color:#cc7832;">print</span>(timeit.timeit(get_features<span style="color:#cc7832;">, </span><span style="color:#aa4926;">number</span>=<span style="color:#6897bb;">100</span>))</pre>
<p>Best regards<br>
Matthias<br>
</p>
<div class="moz-cite-prefix">On 6/17/19 1:03 PM, Andrea Aime wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+nxMTszz7b=0KcAouJih_GnWhW+poJ=wFWQObqjVAP0JztdkQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hey all,
<div>sorry to intrude, but I have a bit of related information.</div>
<div>GeoServer uses the same underlying stack as QGIS, at one
point we noticed that the</div>
<div>reading performance went down, upon investigation it turned
out the JDBC driver</div>
<div>started using SSL by default when available.</div>
<div><br>
</div>
<div>So we added a flag to turn off SSL and it indeed helped
performance (but not 10 times mind,</div>
<div>maybe 20-30% on OSM like map like the one rendering at <a
href="http://geoserver.org" moz-do-not-send="true">geoserver.org</a>,
did not try on simpler/smaller maps). </div>
<div>This was a few months ago, not 10 years ago, so yes, SSL
encrypt/decrypt is still indeed taking a toll.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Andrea</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jun 17, 2019 at 12:46
PM Matthias Kuhn <<a href="mailto:matthias@opengis.ch"
moz-do-not-send="true">matthias@opengis.ch</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
6/17/19 12:16 PM, Martin Dobias wrote:<br>
> On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn <<a
href="mailto:matthias@opengis.ch" target="_blank"
moz-do-not-send="true">matthias@opengis.ch</a>> wrote:<br>
>> Wouldn't connection pooling be such a change. That
certainly was<br>
>> introduced after.<br>
> Pooling was introduced to deal with multi-threaded
rendering and<br>
> should not affect that. There always was a connection
that was kept<br>
> alive while layer(s) using that connection existed.<br>
<br>
Interesting.<br>
<br>
I still can't see any good explanation for the overhead
detected 10 <br>
years ago, do you have an idea what this could be caused by?<br>
<br>
I just can't imagine that an enterprise level database like
postgres <br>
would suffer from such an issue on the security side.<br>
<br>
Cheers Matthias<br>
<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org"
target="_blank" moz-do-not-send="true">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-developer"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-developer"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><span>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font
face="Arial"><span style="font-size:14.6667px;white-space:pre-wrap">Regards,
Andrea Aime
==
GeoServer Professional Services from the experts! Visit <a href="http://goo.gl/it488V" target="_blank" moz-do-not-send="true">http://goo.gl/it488V</a> for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
<a href="http://www.geo-solutions.it" target="_blank" moz-do-not-send="true">http://www.geo-solutions.it</a>
<a href="http://twitter.com/geosolutions_it" target="_blank" moz-do-not-send="true">http://twitter.com/geosolutions_it</a>
-------------------------------------------------------
<i>Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.</i>
</span></font></p>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>