Skip site navigation (1) Skip section navigation (2)

Speed of SSL connections; cost of renegotiation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Speed of SSL connections; cost of renegotiation
Date: 2003-04-10 22:50:02
Message-ID: 7334.1050015002@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
I just derived the following rather interesting numbers concerning the
cost of SSL-encryption in CVS tip.  The test case is to COPY about 40MB
of data to or from a server running on the same machine (RHL 8.0).

Without SSL:

[tgl(at)rh1 tmp]$ time psql -c "\copy foo to 'foo2'" regression

real    0m16.592s
user    0m0.521s
sys     0m0.270s
[tgl(at)rh1 tmp]$ time psql -c "\copy foo from 'foo3'" regression

real    0m20.032s
user    0m2.223s
sys     0m0.217s

With SSL:

[tgl(at)rh1 tmp]$ time psql -c "\copy foo to 'foo2'" -h localhost regression

real    4m18.912s
user    2m30.842s
sys     1m4.076s
[tgl(at)rh1 tmp]$ time psql -c "\copy foo from 'foo3'" -h localhost regression

real    1m10.774s
user    0m29.461s
sys     0m23.494s

In other words, bulk data transfer *to* the server is about 3.5x slower
than it is over an unencrypted Unix socket.  Okay, I can live with that.
But bulk transfer *from* the server is more than 15x slower.  That's
above my threshold of pain.  And considering client and server are the
same machine, why should there be any asymmetry in transfer rate?

It looks to me like the culprit is SSL renegotiation.  The server is
currently programmed to force a renegotiation after every 64K of data
transferred to or from the client.  However, the test to decide to do
a renegotiation was placed only in SSL_write, so a large COPY-to-server
escapes triggering the renegotiation except at the very end, whereas the
COPY-to-file case is indeed executing a renegotiation about every 64K.
Apparently, those renegotiations are horridly expensive.

As an experiment, I increased the renegotiation interval by a factor of
10 (from 64K to 640K).  This brought the COPY-to-file time down to about
47sec, which is more in line with the in/out speed ratio for the
non-encrypted case, and more than a factor of 5 faster than what's in
CVS.

So, questions for the group: where did the decision to renegotiate every
64K come from?  Do we need it at all?  Do we need it at such a short
interval?  And if we do need it, shouldn't the logic be symmetric, so
that renegotiations are forced during large input transfers as well as
large output transfers?

			regards, tom lane


Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2003-04-10 23:29:30
Subject: Re: [HACKERS] More thoughts about FE/BE protocol
Previous:From: Nigel J. AndrewsDate: 2003-04-10 22:40:54
Subject: Re: [HACKERS] More thoughts about FE/BE protocol

pgsql-interfaces by date

Next:From: Tom LaneDate: 2003-04-10 23:29:30
Subject: Re: [HACKERS] More thoughts about FE/BE protocol
Previous:From: Nigel J. AndrewsDate: 2003-04-10 22:40:54
Subject: Re: [HACKERS] More thoughts about FE/BE protocol

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group