Re: SSL encryption makes bytea transfer slow

On Mon, Oct 31, 2011 at 10:34 AM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> Heikki Linnakangas 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?
>
> Thanks for looking at that.
>
>> I tried to reproduce that, but only saw about 4x difference in the
>> timing, not 23x.
>
> I tried more tests on an idle server, and the factor I observe here is
> 3 or 4 as you say.  The original measurements were taken on a server
> under load.
>
>> 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:
>>
>> samples  %        image name               symbol name
>> 28177    74.4753  libz.so.1.2.3.4          /usr/lib/libz.so.1.2.3.4
>> 1814      4.7946  postgres                 byteain
>> 1459      3.8563  libc-2.13.so             __memcpy_ssse3_back
>> 1437      3.7982  libcrypto.so.0.9.8       /usr/lib/libcrypto.so.0.9.8
>> 896       2.3682  postgres                 hex_encode
>> 304       0.8035  vmlinux-3.0.0-1-amd64    clear_page_c
>> 271       0.7163  libc-2.13.so             __strlen_sse42
>> 222       0.5868  libssl.so.0.9.8          /usr/lib/libssl.so.0.9.8
>>
>> And without:
>>
>> samples  %        image name               symbol name
>> 1601     27.4144  postgres                 byteain
>> 865      14.8116  postgres                 hex_encode
>> 835      14.2979  libc-2.13.so             __memcpy_ssse3_back
>> 290       4.9658  vmlinux-3.0.0-1-amd64    clear_page_c
>> 280       4.7945  libc-2.13.so             __strlen_sse42
>> 184       3.1507  vmlinux-3.0.0-1-amd64    page_fault
>> 174       2.9795  vmlinux-3.0.0-1-amd64    put_mems_allowed
>>
>>
>> Maybe your data is very expensive to compress for some reason?
>
> 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:
>
> With SSL:
>
> 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.

merlin