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
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? |