Re: SSL encryption makes bytea transfer slow

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Heikki Linnakangas *EXTERN*" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSL encryption makes bytea transfer slow
Date: 2011-10-31 15:34:55
Message-ID: D960CB61B694CF459DCFB4B0128514C2070C413B@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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
755 11.009 byteaout
/magwien/postgres-8.4.8/bin/postgres
378 5.51181 __GI_memcpy /lib/tls/libc-2.3.2.so
220 3.20793 printtup
/magwien/postgres-8.4.8/bin/postgres

Without SSL:

samples % symbol name image name
765 55.8394 byteaout
/magwien/postgres-8.4.8/bin/postgres
293 21.3869 __GI_memcpy /lib/tls/libc-2.3.2.so
220 16.0584 printtup
/magwien/postgres-8.4.8/bin/postgres

Could that still be compression?

The test I am running is:

$ psql "host=localhost sslmode=... dbname=test"
test=> \o /dev/null
test=> select val from images where id=2;
test=> \q

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Sören Meyer-Eppler 2011-10-31 16:17:15 Re: PostgreSQL 9.0.4 blocking in lseek?
Previous Message Tom Lane 2011-10-31 15:28:01 Re: PostgreSQL 9.0.4 blocking in lseek?