Re: Disable OpenSSL compression
От | Andrew Dunstan |
---|---|
Тема | Re: Disable OpenSSL compression |
Дата | |
Msg-id | 4EB9408A.1010105@dunslane.net обсуждение исходный текст |
Ответ на | Re: Disable OpenSSL compression (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Disable OpenSSL compression
|
Список | pgsql-hackers |
On 11/08/2011 09:34 AM, Tom Lane wrote: > Marko Kreen<markokr@gmail.com> writes: >> On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz<laurenz.albe@wien.gv.at> wrote: >>> It is possible that this could cause a performance >>> regression for people who SELECT lots of compressible >>> data over really slow network connections, but is that >>> a realistic scenario? >> Yes, it's a realistic scenario. Please make it a option. > I distinctly recall us getting bashed a few years ago because there > wasn't any convenient way to turn SSL compression *on*. Now that SSL > finally does the sane thing by default, you want to turn it off? > > The fact of the matter is that in most situations where you want SSL, > ie links across insecure WANs, compression is a win. Testing a local > connection, as you seem to have done, is just about 100% irrelevant to > performance in the real world. > > There might be some argument for providing a client option to disable > compression, but it should not be forced, and it shouldn't even be the > default. But before adding YA connection option, I'd want to see some > evidence that it's useful over non-local connections. I can certainly conceive of situations where one wants SSL on a high speed/bandwidth network. I don't think we should assume that all or even most real world SSL use will be across slow networks. Here's another data point: <http://journal.paul.querna.org/articles/2011/04/05/openssl-memory-use/> cheers andrew
В списке pgsql-hackers по дате отправления: