Merlin Moncure wrote:
>>>> We selected a 30MB bytea with psql connected with
>>>> "-h localhost" and found that it makes a huge
>>>> difference whether we have SSL encryption on or off.
>>>>
>>>> Without SSL the SELECT finished in about a second,
>>>> with SSL it took over 23 seconds (measured with
>>>> \timing in psql).
>>>> During that time, the CPU is 100% busy.
>>>> All data are cached in memory.
>>>>
>>>> Is this difference as expected?
>>> I tried to reproduce that, but only saw about 4x difference in the
>>> timing, not 23x.
>>> oprofile suggests that all that overhead is coming from compression.
>>> Apparently SSL does compression automatically. Oprofile report of the
>>> above test case with SSL enabled:
[...]
>> Funny, I cannot see any calls to libz. On my system (RHEL 3, PostgreSQL
>> 8.4.8, openssl 0.9.7a) the oprofile reports of the server process look
>> like this:
>> samples % symbol name image name
>> 5326 77.6611 (no symbol) /lib/libcrypto.so.0.9.7a
> that's a pretty ancient crypto you got there...it may not compress by
> default. Heikki's test data will compress super well which would
> totally skew performance testing to libz since the amount of data
> actually encrypted will be fairly tiny. real world high entropy cases
> often show crypto as the worse offender in my experience.
I experimented some more on a recent system (RHEL6, OpenSSL 1.0.0-fips),
and it is as you say. Disabling OpenSSL compression in the source (which
is possible since OpenSSL 1.0.0) does not give me any performance
improvement.
Seems you pretty much have to live with at most 1/4 of the performance
if you want to SELECT large images using SSL.
Yours,
Laurenz Albe