On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> 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.
+1 for keeping current default.
But I can imagine scenarios where having option to turn compression
off could be useful:
- when minimal latency is required
- when "normal" latency is required, but data is big
- when serving big non-compressible blobs - zlib can be very slow
- when serving lots of connections and want to minimize unnecessary cpu and memory load
Depending on how zlib is used by openssl, some of
them may not happen in practice.
--
marko
