On Mon, Oct 31, 2011 at 10:34 AM, Albe Laurenz <laurenz.albe@xxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
