[QGIS-Developer] SSL Performance Overhead

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[QGIS-Developer] SSL Performance Overhead

Matthias Kuhn 🌍
Hi,

The documentation currently promises "massive speed-ups in PostGIS layer
rendering" with SSL disabled. [1]

I find some references to performance cost of SSL but they should be
compensated for with connection pooling which we use for quite some time
already.

Recently, the web is more and more encrypted - and that is very good! -
so I think we should also start to encourage people to encrypt their SSL
connections. Or at least certainly not discourage them from using
encryption by promising performance benefits.

Is there anyone who knows why this sentence was introduced? And if there
is (still) an issue with performance when using SSL?

Best regards

Matthias

[1]
https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection

[2] https://github.com/qgis/QGIS-Documentation/pull/3840

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Andreas Neumann-4

Hi,

I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company.

Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data".

For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel).

Sorry, I don't have any data on the overhead of SSL connections though.

Andreas

On 2019-06-17 08:48, Matthias Kuhn wrote:

Hi,

The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1]

I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already.

Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits.

Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL?

Best regards

Matthias

[1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection

[2] https://github.com/qgis/QGIS-Documentation/pull/3840

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Martin Dobias
In reply to this post by Matthias Kuhn 🌍
Hi Matthias

On Mon, Jun 17, 2019 at 8:48 AM Matthias Kuhn <[hidden email]> wrote:
>
> The documentation currently promises "massive speed-ups in PostGIS layer
> rendering" with SSL disabled. [1]
>
> [...]
>
> Is there anyone who knows why this sentence was introduced? And if there
> is (still) an issue with performance when using SSL?

As Jurgen has commented on the pull request already, we have figured
out that QGIS was taking a lot more time to access features from a
local PostgreSQL database compared to some other app (uDig?). I have
dug out an old mail with the measurement - the difference was ~12
seconds to fetch data in QGIS vs ~4 seconds to fetch data in the other
app. In the end we figured out that disabling encryption removed that
penalization. All that was back in 2009 :-)

Unless there have been some improvements in the server/client lib, I
think the promise of massive speed up is still valid... And as Andreas
mentions, most(?) of the time people use the DB on a local network, so
it should not be a big deal to send data on local network unencrypted.

Cheers
Martin
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Mathieu Pellerin
For the record, sending unencrypted data over a local network isn't safe as soon as WIFI is part of said local network.

On Mon, Jun 17, 2019, 17:02 Martin Dobias <[hidden email]> wrote:
Hi Matthias

On Mon, Jun 17, 2019 at 8:48 AM Matthias Kuhn <[hidden email]> wrote:
>
> The documentation currently promises "massive speed-ups in PostGIS layer
> rendering" with SSL disabled. [1]
>
> [...]
>
> Is there anyone who knows why this sentence was introduced? And if there
> is (still) an issue with performance when using SSL?

As Jurgen has commented on the pull request already, we have figured
out that QGIS was taking a lot more time to access features from a
local PostgreSQL database compared to some other app (uDig?). I have
dug out an old mail with the measurement - the difference was ~12
seconds to fetch data in QGIS vs ~4 seconds to fetch data in the other
app. In the end we figured out that disabling encryption removed that
penalization. All that was back in 2009 :-)

Unless there have been some improvements in the server/client lib, I
think the promise of massive speed up is still valid... And as Andreas
mentions, most(?) of the time people use the DB on a local network, so
it should not be a big deal to send data on local network unencrypted.

Cheers
Martin
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Matthias Kuhn 🌍
In reply to this post by Martin Dobias
Wouldn't connection pooling be such a change. That certainly was
introduced after.

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Martin Dobias
On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn <[hidden email]> wrote:
>
> Wouldn't connection pooling be such a change. That certainly was
> introduced after.

Pooling was introduced to deal with multi-threaded rendering and
should not affect that. There always was a connection that was kept
alive while layer(s) using that connection existed.

Cheers
Martin
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Matthias Kuhn 🌍
On 6/17/19 12:16 PM, Martin Dobias wrote:
> On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn <[hidden email]> wrote:
>> Wouldn't connection pooling be such a change. That certainly was
>> introduced after.
> Pooling was introduced to deal with multi-threaded rendering and
> should not affect that. There always was a connection that was kept
> alive while layer(s) using that connection existed.

Interesting.

I still can't see any good explanation for the overhead detected 10
years ago, do you have an idea what this could be caused by?

I just can't imagine that an enterprise level database like postgres
would suffer from such an issue on the security side.

Cheers Matthias

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

geowolf
Hey all,
sorry to intrude, but I have a bit of related information.
GeoServer uses the same underlying stack as QGIS, at one point we noticed that the
reading performance went down, upon investigation it turned out the JDBC driver
started using SSL by default when available.

So we added a flag to turn off SSL and it indeed helped performance (but not 10 times mind,
maybe 20-30% on OSM like map like the one rendering at geoserver.org, did not try on simpler/smaller maps). 
This was a few months ago, not 10 years ago, so yes, SSL encrypt/decrypt is still indeed taking a toll.

Cheers
Andrea


On Mon, Jun 17, 2019 at 12:46 PM Matthias Kuhn <[hidden email]> wrote:
On 6/17/19 12:16 PM, Martin Dobias wrote:
> On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn <[hidden email]> wrote:
>> Wouldn't connection pooling be such a change. That certainly was
>> introduced after.
> Pooling was introduced to deal with multi-threaded rendering and
> should not affect that. There always was a connection that was kept
> alive while layer(s) using that connection existed.

Interesting.

I still can't see any good explanation for the overhead detected 10
years ago, do you have an idea what this could be caused by?

I just can't imagine that an enterprise level database like postgres
would suffer from such an issue on the security side.

Cheers Matthias

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


--

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V 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 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- 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.


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

geowolf
On Mon, Jun 17, 2019 at 1:03 PM Andrea Aime <[hidden email]> wrote:
Hey all,
sorry to intrude, but I have a bit of related information.
GeoServer uses the same underlying stack as QGIS

Sorry not as QGIS, same as UDig!

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V 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 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- 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.


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Stefan Steiger
In reply to this post by Andreas Neumann-4

One of our customers (Swiss National Bank) mandates the use of SSL in their internal LAN, even for DB connections.  

Using anything but SSL is an insecure mode of communication, even in LAN.

RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, recommended 256.

 

-          Only latest version of OpenSSL allowed

-          Accepted TLS 1.1+, recommended TLS 1.2+

-          SSL Version 3.0 or older are explicitly forbidden

-          Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit

-          Extended Validation certificates have to be used

-          Wildcards in fully qualified names not allowed

-          Accepted: CTR/CBC/CCM/EAX, recommended GCM

-          SSL accepted with forward secrecy Disabled, recommended Enabled

-          Recommended CryptRandom: /dev/random, /dev/urandom,

 

as per IT Security Baseline 2017-07-20

 

 

Von: QGIS-Developer [mailto:[hidden email]] Im Auftrag von Andreas Neumann
Gesendet: Montag, 17. Juni 2019 09:05
An: Matthias Kuhn <[hidden email]>
Cc: [hidden email]
Betreff: Re: [QGIS-Developer] SSL Performance Overhead

 

Hi,

I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company.

Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data".

For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel).

Sorry, I don't have any data on the overhead of SSL connections though.

Andreas

On 2019-06-17 08:48, Matthias Kuhn wrote:

Hi,

The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1]

I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already.

Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits.

Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL?

Best regards

Matthias

[1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection

[2] https://github.com/qgis/QGIS-Documentation/pull/3840

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

 


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Andreas Neumann-4

Hi Stefan,

Yes, sure. If I were a bank or the national bank I would also mandate use of SSL. Also, when personal data is involved. But many gov authorities have primarily publically available geoinformation (object data, no personal data) in their DBs and no sensitive data.

We are just discussing the defaults, anyone can enable SSL if it is useful or required in their usage scenario.

Andreas

On 2019-06-17 13:20, Stefan Steiger wrote:

One of our customers (Swiss National Bank) mandates the use of SSL in their internal LAN, even for DB connections.  

Using anything but SSL is an insecure mode of communication, even in LAN.

RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, recommended 256.

 

-          Only latest version of OpenSSL allowed

-          Accepted TLS 1.1+, recommended TLS 1.2+

-          SSL Version 3.0 or older are explicitly forbidden

-          Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit

-          Extended Validation certificates have to be used

-          Wildcards in fully qualified names not allowed

-          Accepted: CTR/CBC/CCM/EAX, recommended GCM

-          SSL accepted with forward secrecy Disabled, recommended Enabled

-          Recommended CryptRandom: /dev/random, /dev/urandom,

 

as per IT Security Baseline 2017-07-20

 

 

Von: QGIS-Developer [mailto:[hidden email]] Im Auftrag von Andreas Neumann
Gesendet: Montag, 17. Juni 2019 09:05
An: Matthias Kuhn <[hidden email]>
Cc: [hidden email]
Betreff: Re: [QGIS-Developer] SSL Performance Overhead

 

Hi,

I would say, that the use of SSL should be encouraged if the connection goes through public networks. If the Postgis connection is within the company LAN I don't see a strong reason for enabling SSL, unless the company LAN is designed in an "unsafe" way, or if sensitive data must be hidden from other employees in the same company.

Personally, I never had good results (performance wise) if Postgis connections went through the public Internet, unless it is some "toy data".

For this reason, I usually used streaming replication to replicate Postgis, so it is as close as possible to the users who need the data. The streaming replication, if it goes through the public internet, of course should use SSL (or often it goes through an SSH tunnel).

Sorry, I don't have any data on the overhead of SSL connections though.

Andreas

On 2019-06-17 08:48, Matthias Kuhn wrote:

Hi,

The documentation currently promises "massive speed-ups in PostGIS layer rendering" with SSL disabled. [1]

I find some references to performance cost of SSL but they should be compensated for with connection pooling which we use for quite some time already.

Recently, the web is more and more encrypted - and that is very good! - so I think we should also start to encourage people to encrypt their SSL connections. Or at least certainly not discourage them from using encryption by promising performance benefits.

Is there anyone who knows why this sentence was introduced? And if there is (still) an issue with performance when using SSL?

Best regards

Matthias

[1] https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection

[2] https://github.com/qgis/QGIS-Documentation/pull/3840

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

 



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Bernhard Ströbl
Hi all,

I have to add that we use SSL to encrypt the user credentials as we use
LDAP to authentificate users at the database. So SSL is not only
relevant looking at data stored in the database.
Bernhard

Am 17.06.2019 um 13:56 schrieb Andreas Neumann:

> Hi Stefan,
>
> Yes, sure. If I were a bank or the national bank I would also mandate
> use of SSL. Also, when personal data is involved. But many gov
> authorities have primarily publically available geoinformation (object
> data, no personal data) in their DBs and no sensitive data.
>
> We are just discussing the defaults, anyone can enable SSL if it is
> useful or required in their usage scenario.
>
> Andreas
>
> On 2019-06-17 13:20, Stefan Steiger wrote:
>
>> One of our customers (Swiss National Bank) mandates the use of SSL in
>> their internal LAN, even for DB connections.
>>
>> Using anything but SSL is an insecure mode of communication, even in LAN.
>>
>> RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is
>> 160 Bit, recommended 256.
>>
>> -Only latest version of OpenSSL allowed
>>
>> -Accepted TLS 1.1+, recommended TLS 1.2+
>>
>> -SSL Version 3.0 or older are explicitly forbidden
>>
>> -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit
>>
>> -Extended Validation certificates have to be used
>>
>> -Wildcards in fully qualified names not allowed
>>
>> -Accepted: CTR/CBC/CCM/EAX, recommended GCM
>>
>> -SSL accepted with forward secrecy Disabled, recommended Enabled
>>
>> -Recommended CryptRandom: /dev/random, /dev/urandom,
>>
>> as per IT Security Baseline 2017-07-20
>>
>> *Von:*QGIS-Developer [mailto:[hidden email]]
>> *Im Auftrag von *Andreas Neumann
>> *Gesendet:* Montag, 17. Juni 2019 09:05
>> *An:* Matthias Kuhn <[hidden email]>
>> *Cc:* [hidden email]
>> *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead
>>
>> Hi,
>>
>> I would say, that the use of SSL should be encouraged if the
>> connection goes through public networks. If the Postgis connection is
>> within the company LAN I don't see a strong reason for enabling SSL,
>> unless the company LAN is designed in an "unsafe" way, or if sensitive
>> data must be hidden from other employees in the same company.
>>
>> Personally, I never had good results (performance wise) if Postgis
>> connections went through the public Internet, unless it is some "toy
>> data".
>>
>> For this reason, I usually used streaming replication to replicate
>> Postgis, so it is as close as possible to the users who need the data.
>> The streaming replication, if it goes through the public internet, of
>> course should use SSL (or often it goes through an SSH tunnel).
>>
>> Sorry, I don't have any data on the overhead of SSL connections though.
>>
>> Andreas
>>
>> On 2019-06-17 08:48, Matthias Kuhn wrote:
>>
>>     Hi,
>>
>>     The documentation currently promises "massive speed-ups in PostGIS
>>     layer rendering" with SSL disabled. [1
>>     <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection>]
>>
>>     I find some references to performance cost of SSL but they should
>>     be compensated for with connection pooling which we use for quite
>>     some time already.
>>
>>     Recently, the web is more and more encrypted - and that is very
>>     good! - so I think we should also start to encourage people to
>>     encrypt their SSL connections. Or at least certainly not
>>     discourage them from using encryption by promising performance
>>     benefits.
>>
>>     Is there anyone who knows why this sentence was introduced? And if
>>     there is (still) an issue with performance when using SSL?
>>
>>     Best regards
>>
>>     Matthias
>>
>>     [1]
>>     https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection
>>     <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection>
>>
>>     [2] https://github.com/qgis/QGIS-Documentation/pull/3840
>>
>>     _______________________________________________
>>     QGIS-Developer mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
>
> __________ Information from ESET Mail Security, version of virus
> signature database 19536 (20190617) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>





__________ Information from ESET Mail Security, version of virus signature database 19537 (20190617) __________

The message was checked by ESET Mail Security.
http://www.eset.com


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Stefan Steiger
Uh, ah, yea, also, sending a password for a DB-user over the intranet-network in plain text is rather bad.
While the data retrieved from the DB might not be confidential, maybe there is confidential data in the db.
Also, the login used could have permissions onto another DB that has confidential data inside.

In my opinion, the default should be SSL, including in intranet.  
If anybody changes the default for performance reasons, they can, and correspondingly, the blame will be theirs if anything happens.
Nowadays, we use SSL even in development.
Just my 0.05 $


-----Ursprüngliche Nachricht-----
Von: QGIS-Developer [mailto:[hidden email]] Im Auftrag von Bernhard Ströbl
Gesendet: Montag, 17. Juni 2019 15:31
An: [hidden email]
Betreff: Re: [QGIS-Developer] SSL Performance Overhead

Hi all,

I have to add that we use SSL to encrypt the user credentials as we use LDAP to authentificate users at the database. So SSL is not only relevant looking at data stored in the database.
Bernhard

Am 17.06.2019 um 13:56 schrieb Andreas Neumann:

> Hi Stefan,
>
> Yes, sure. If I were a bank or the national bank I would also mandate
> use of SSL. Also, when personal data is involved. But many gov
> authorities have primarily publically available geoinformation (object
> data, no personal data) in their DBs and no sensitive data.
>
> We are just discussing the defaults, anyone can enable SSL if it is
> useful or required in their usage scenario.
>
> Andreas
>
> On 2019-06-17 13:20, Stefan Steiger wrote:
>
>> One of our customers (Swiss National Bank) mandates the use of SSL in
>> their internal LAN, even for DB connections.
>>
>> Using anything but SSL is an insecure mode of communication, even in LAN.
>>
>> RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is
>> 160 Bit, recommended 256.
>>
>> -Only latest version of OpenSSL allowed
>>
>> -Accepted TLS 1.1+, recommended TLS 1.2+
>>
>> -SSL Version 3.0 or older are explicitly forbidden
>>
>> -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit
>>
>> -Extended Validation certificates have to be used
>>
>> -Wildcards in fully qualified names not allowed
>>
>> -Accepted: CTR/CBC/CCM/EAX, recommended GCM
>>
>> -SSL accepted with forward secrecy Disabled, recommended Enabled
>>
>> -Recommended CryptRandom: /dev/random, /dev/urandom,
>>
>> as per IT Security Baseline 2017-07-20
>>
>> *Von:*QGIS-Developer [mailto:[hidden email]]
>> *Im Auftrag von *Andreas Neumann
>> *Gesendet:* Montag, 17. Juni 2019 09:05
>> *An:* Matthias Kuhn <[hidden email]>
>> *Cc:* [hidden email]
>> *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead
>>
>> Hi,
>>
>> I would say, that the use of SSL should be encouraged if the
>> connection goes through public networks. If the Postgis connection is
>> within the company LAN I don't see a strong reason for enabling SSL,
>> unless the company LAN is designed in an "unsafe" way, or if
>> sensitive data must be hidden from other employees in the same company.
>>
>> Personally, I never had good results (performance wise) if Postgis
>> connections went through the public Internet, unless it is some "toy
>> data".
>>
>> For this reason, I usually used streaming replication to replicate
>> Postgis, so it is as close as possible to the users who need the data.
>> The streaming replication, if it goes through the public internet, of
>> course should use SSL (or often it goes through an SSH tunnel).
>>
>> Sorry, I don't have any data on the overhead of SSL connections though.
>>
>> Andreas
>>
>> On 2019-06-17 08:48, Matthias Kuhn wrote:
>>
>>     Hi,
>>
>>     The documentation currently promises "massive speed-ups in PostGIS
>>     layer rendering" with SSL disabled. [1
>>    
>> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/
>> opening_data.html#creating-a-stored-connection>]
>>
>>     I find some references to performance cost of SSL but they should
>>     be compensated for with connection pooling which we use for quite
>>     some time already.
>>
>>     Recently, the web is more and more encrypted - and that is very
>>     good! - so I think we should also start to encourage people to
>>     encrypt their SSL connections. Or at least certainly not
>>     discourage them from using encryption by promising performance
>>     benefits.
>>
>>     Is there anyone who knows why this sentence was introduced? And if
>>     there is (still) an issue with performance when using SSL?
>>
>>     Best regards
>>
>>     Matthias
>>
>>     [1]
>>     https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection
>>    
>> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/
>> opening_data.html#creating-a-stored-connection>
>>
>>     [2] https://github.com/qgis/QGIS-Documentation/pull/3840
>>
>>     _______________________________________________
>>     QGIS-Developer mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>     Unsubscribe:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
>
> __________ Information from ESET Mail Security, version of virus
> signature database 19536 (20190617) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>





__________ Information from ESET Mail Security, version of virus signature database 19537 (20190617) __________

The message was checked by ESET Mail Security.
http://www.eset.com


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Bo Victor Thomsen
Has anyone tried to ascertain how big the overhead is when using SSL -
and why ?

Regards

Bo Victor Thomsen
AestasGIS Denamrk


Den 18-06-2019 kl. 14:15 skrev Stefan Steiger:

> Uh, ah, yea, also, sending a password for a DB-user over the intranet-network in plain text is rather bad.
> While the data retrieved from the DB might not be confidential, maybe there is confidential data in the db.
> Also, the login used could have permissions onto another DB that has confidential data inside.
>
> In my opinion, the default should be SSL, including in intranet.
> If anybody changes the default for performance reasons, they can, and correspondingly, the blame will be theirs if anything happens.
> Nowadays, we use SSL even in development.
> Just my 0.05 $
>
>
> -----Ursprüngliche Nachricht-----
> Von: QGIS-Developer [mailto:[hidden email]] Im Auftrag von Bernhard Ströbl
> Gesendet: Montag, 17. Juni 2019 15:31
> An: [hidden email]
> Betreff: Re: [QGIS-Developer] SSL Performance Overhead
>
> Hi all,
>
> I have to add that we use SSL to encrypt the user credentials as we use LDAP to authentificate users at the database. So SSL is not only relevant looking at data stored in the database.
> Bernhard
>
> Am 17.06.2019 um 13:56 schrieb Andreas Neumann:
>> Hi Stefan,
>>
>> Yes, sure. If I were a bank or the national bank I would also mandate
>> use of SSL. Also, when personal data is involved. But many gov
>> authorities have primarily publically available geoinformation (object
>> data, no personal data) in their DBs and no sensitive data.
>>
>> We are just discussing the defaults, anyone can enable SSL if it is
>> useful or required in their usage scenario.
>>
>> Andreas
>>
>> On 2019-06-17 13:20, Stefan Steiger wrote:
>>
>>> One of our customers (Swiss National Bank) mandates the use of SSL in
>>> their internal LAN, even for DB connections.
>>>
>>> Using anything but SSL is an insecure mode of communication, even in LAN.
>>>
>>> RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is
>>> 160 Bit, recommended 256.
>>>
>>> -Only latest version of OpenSSL allowed
>>>
>>> -Accepted TLS 1.1+, recommended TLS 1.2+
>>>
>>> -SSL Version 3.0 or older are explicitly forbidden
>>>
>>> -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit
>>>
>>> -Extended Validation certificates have to be used
>>>
>>> -Wildcards in fully qualified names not allowed
>>>
>>> -Accepted: CTR/CBC/CCM/EAX, recommended GCM
>>>
>>> -SSL accepted with forward secrecy Disabled, recommended Enabled
>>>
>>> -Recommended CryptRandom: /dev/random, /dev/urandom,
>>>
>>> as per IT Security Baseline 2017-07-20
>>>
>>> *Von:*QGIS-Developer [mailto:[hidden email]]
>>> *Im Auftrag von *Andreas Neumann
>>> *Gesendet:* Montag, 17. Juni 2019 09:05
>>> *An:* Matthias Kuhn <[hidden email]>
>>> *Cc:* [hidden email]
>>> *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead
>>>
>>> Hi,
>>>
>>> I would say, that the use of SSL should be encouraged if the
>>> connection goes through public networks. If the Postgis connection is
>>> within the company LAN I don't see a strong reason for enabling SSL,
>>> unless the company LAN is designed in an "unsafe" way, or if
>>> sensitive data must be hidden from other employees in the same company.
>>>
>>> Personally, I never had good results (performance wise) if Postgis
>>> connections went through the public Internet, unless it is some "toy
>>> data".
>>>
>>> For this reason, I usually used streaming replication to replicate
>>> Postgis, so it is as close as possible to the users who need the data.
>>> The streaming replication, if it goes through the public internet, of
>>> course should use SSL (or often it goes through an SSH tunnel).
>>>
>>> Sorry, I don't have any data on the overhead of SSL connections though.
>>>
>>> Andreas
>>>
>>> On 2019-06-17 08:48, Matthias Kuhn wrote:
>>>
>>>      Hi,
>>>
>>>      The documentation currently promises "massive speed-ups in PostGIS
>>>      layer rendering" with SSL disabled. [1
>>>      
>>> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/
>>> opening_data.html#creating-a-stored-connection>]
>>>
>>>      I find some references to performance cost of SSL but they should
>>>      be compensated for with connection pooling which we use for quite
>>>      some time already.
>>>
>>>      Recently, the web is more and more encrypted - and that is very
>>>      good! - so I think we should also start to encourage people to
>>>      encrypt their SSL connections. Or at least certainly not
>>>      discourage them from using encryption by promising performance
>>>      benefits.
>>>
>>>      Is there anyone who knows why this sentence was introduced? And if
>>>      there is (still) an issue with performance when using SSL?
>>>
>>>      Best regards
>>>
>>>      Matthias
>>>
>>>      [1]
>>>      https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection
>>>      
>>> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/
>>> opening_data.html#creating-a-stored-connection>
>>>
>>>      [2] https://github.com/qgis/QGIS-Documentation/pull/3840
>>>
>>>      _______________________________________________
>>>      QGIS-Developer mailing list
>>>      [hidden email] <mailto:[hidden email]>
>>>      List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>      Unsubscribe:
>>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> __________ Information from ESET Mail Security, version of virus
>> signature database 19536 (20190617) __________
>>
>> The message was checked by ESET Mail Security.
>> http://www.eset.com
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
>
>
> __________ Information from ESET Mail Security, version of virus signature database 19537 (20190617) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Jonathan Moules-4
This has been covered a few times on StackOverflow.
https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
https://stackoverflow.com/questions/149274/http-vs-https-performance

Basically, the expensive part is creating the connection (handshaking).
After that, when using the connection the overhead should be minimal.
Given this I'd suggest the obvious starting point for investigating is
to confirm it's not recreating the connection over-and-over.

Because it's a database connection it's unlikely there's a slow-down due
to a lack of caching.

Cheers,
Jonathan

On 18/06/2019 13:28, Bo Victor Thomsen wrote:

> Has anyone tried to ascertain how big the overhead is when using SSL -
> and why ?
>
> Regards
>
> Bo Victor Thomsen
> AestasGIS Denamrk
>
>
> Den 18-06-2019 kl. 14:15 skrev Stefan Steiger:
>> Uh, ah, yea, also, sending a password for a DB-user over the
>> intranet-network in plain text is rather bad.
>> While the data retrieved from the DB might not be confidential, maybe
>> there is confidential data in the db.
>> Also, the login used could have permissions onto another DB that has
>> confidential data inside.
>>
>> In my opinion, the default should be SSL, including in intranet.
>> If anybody changes the default for performance reasons, they can, and
>> correspondingly, the blame will be theirs if anything happens.
>> Nowadays, we use SSL even in development.
>> Just my 0.05 $
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: QGIS-Developer [mailto:[hidden email]]
>> Im Auftrag von Bernhard Ströbl
>> Gesendet: Montag, 17. Juni 2019 15:31
>> An: [hidden email]
>> Betreff: Re: [QGIS-Developer] SSL Performance Overhead
>>
>> Hi all,
>>
>> I have to add that we use SSL to encrypt the user credentials as we
>> use LDAP to authentificate users at the database. So SSL is not only
>> relevant looking at data stored in the database.
>> Bernhard
>>
>> Am 17.06.2019 um 13:56 schrieb Andreas Neumann:
>>> Hi Stefan,
>>>
>>> Yes, sure. If I were a bank or the national bank I would also mandate
>>> use of SSL. Also, when personal data is involved. But many gov
>>> authorities have primarily publically available geoinformation (object
>>> data, no personal data) in their DBs and no sensitive data.
>>>
>>> We are just discussing the defaults, anyone can enable SSL if it is
>>> useful or required in their usage scenario.
>>>
>>> Andreas
>>>
>>> On 2019-06-17 13:20, Stefan Steiger wrote:
>>>
>>>> One of our customers (Swiss National Bank) mandates the use of SSL in
>>>> their internal LAN, even for DB connections.
>>>>
>>>> Using anything but SSL is an insecure mode of communication, even
>>>> in LAN.
>>>>
>>>> RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is
>>>> 160 Bit, recommended 256.
>>>>
>>>> -Only latest version of OpenSSL allowed
>>>>
>>>> -Accepted TLS 1.1+, recommended TLS 1.2+
>>>>
>>>> -SSL Version 3.0 or older are explicitly forbidden
>>>>
>>>> -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit
>>>>
>>>> -Extended Validation certificates have to be used
>>>>
>>>> -Wildcards in fully qualified names not allowed
>>>>
>>>> -Accepted: CTR/CBC/CCM/EAX, recommended GCM
>>>>
>>>> -SSL accepted with forward secrecy Disabled, recommended Enabled
>>>>
>>>> -Recommended CryptRandom: /dev/random, /dev/urandom,
>>>>
>>>> as per IT Security Baseline 2017-07-20
>>>>
>>>> *Von:*QGIS-Developer [mailto:[hidden email]]
>>>> *Im Auftrag von *Andreas Neumann
>>>> *Gesendet:* Montag, 17. Juni 2019 09:05
>>>> *An:* Matthias Kuhn <[hidden email]>
>>>> *Cc:* [hidden email]
>>>> *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead
>>>>
>>>> Hi,
>>>>
>>>> I would say, that the use of SSL should be encouraged if the
>>>> connection goes through public networks. If the Postgis connection is
>>>> within the company LAN I don't see a strong reason for enabling SSL,
>>>> unless the company LAN is designed in an "unsafe" way, or if
>>>> sensitive data must be hidden from other employees in the same
>>>> company.
>>>>
>>>> Personally, I never had good results (performance wise) if Postgis
>>>> connections went through the public Internet, unless it is some "toy
>>>> data".
>>>>
>>>> For this reason, I usually used streaming replication to replicate
>>>> Postgis, so it is as close as possible to the users who need the data.
>>>> The streaming replication, if it goes through the public internet, of
>>>> course should use SSL (or often it goes through an SSH tunnel).
>>>>
>>>> Sorry, I don't have any data on the overhead of SSL connections
>>>> though.
>>>>
>>>> Andreas
>>>>
>>>> On 2019-06-17 08:48, Matthias Kuhn wrote:
>>>>
>>>>      Hi,
>>>>
>>>>      The documentation currently promises "massive speed-ups in
>>>> PostGIS
>>>>      layer rendering" with SSL disabled. [1
>>>> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/
>>>> opening_data.html#creating-a-stored-connection>]
>>>>
>>>>      I find some references to performance cost of SSL but they should
>>>>      be compensated for with connection pooling which we use for quite
>>>>      some time already.
>>>>
>>>>      Recently, the web is more and more encrypted - and that is very
>>>>      good! - so I think we should also start to encourage people to
>>>>      encrypt their SSL connections. Or at least certainly not
>>>>      discourage them from using encryption by promising performance
>>>>      benefits.
>>>>
>>>>      Is there anyone who knows why this sentence was introduced?
>>>> And if
>>>>      there is (still) an issue with performance when using SSL?
>>>>
>>>>      Best regards
>>>>
>>>>      Matthias
>>>>
>>>>      [1]
>>>> https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection
>>>> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/
>>>> opening_data.html#creating-a-stored-connection>
>>>>
>>>>      [2] https://github.com/qgis/QGIS-Documentation/pull/3840
>>>>
>>>>      _______________________________________________
>>>>      QGIS-Developer mailing list
>>>>      [hidden email]
>>>> <mailto:[hidden email]>
>>>>      List info:
>>>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>      Unsubscribe:
>>>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>
>>>
>>>
>>> __________ Information from ESET Mail Security, version of virus
>>> signature database 19536 (20190617) __________
>>>
>>> The message was checked by ESET Mail Security.
>>> http://www.eset.com
>>>
>>> _______________________________________________
>>> QGIS-Developer mailing list
>>> [hidden email]
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>>
>>
>> __________ Information from ESET Mail Security, version of virus
>> signature database 19537 (20190617) __________
>>
>> The message was checked by ESET Mail Security.
>> http://www.eset.com
>>
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> _______________________________________________
>> QGIS-Developer mailing list
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL Performance Overhead

Matthias Kuhn 🌍
In reply to this post by geowolf

Hi Andrea,

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?


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).

The only thing I can think of that I didn't measure in my tests were roundtrips (because the server was run locally).

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.


Scenario:

  Docker container from the QGIS tests (https://github.com/qgis/QGIS/blob/master/.ci/travis/linux/docker-compose.travis.yml)

  docker-compose -f .ci/travis/linux/docker-compose.travis.yml up --build postgres

  # wget https://github.com/QGEP/datamodel/releases/download/1.3.0/qgep_v1.3.0_structure_and_demo_data.backup

  pg_restore -U docker -d gis -h 172.19.0.2 -1 qgep_v1.3.0_structure_and_demo_data.backup

  Restart QGIS with ~/.pg_service.conf with

    - `sslmode=require`

    - `sslmode=disabled`

  Running the following snippet

import timeit
def get_features():
    for f in iface.activeLayer().getFeatures():
        pass

print(timeit.timeit(get_features, number=100))

Best regards
Matthias

On 6/17/19 1:03 PM, Andrea Aime wrote:
Hey all,
sorry to intrude, but I have a bit of related information.
GeoServer uses the same underlying stack as QGIS, at one point we noticed that the
reading performance went down, upon investigation it turned out the JDBC driver
started using SSL by default when available.

So we added a flag to turn off SSL and it indeed helped performance (but not 10 times mind,
maybe 20-30% on OSM like map like the one rendering at geoserver.org, did not try on simpler/smaller maps). 
This was a few months ago, not 10 years ago, so yes, SSL encrypt/decrypt is still indeed taking a toll.

Cheers
Andrea


On Mon, Jun 17, 2019 at 12:46 PM Matthias Kuhn <[hidden email]> wrote:
On 6/17/19 12:16 PM, Martin Dobias wrote:
> On Mon, Jun 17, 2019 at 12:11 PM Matthias Kuhn <[hidden email]> wrote:
>> Wouldn't connection pooling be such a change. That certainly was
>> introduced after.
> Pooling was introduced to deal with multi-threaded rendering and
> should not affect that. There always was a connection that was kept
> alive while layer(s) using that connection existed.

Interesting.

I still can't see any good explanation for the overhead detected 10
years ago, do you have an idea what this could be caused by?

I just can't imagine that an enterprise level database like postgres
would suffer from such an issue on the security side.

Cheers Matthias

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


--

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V 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 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- 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.


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer