From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
To: pgsql-interfaces@postgreSQL.org
Subject: Speed of SSL connections; cost of renegotiation
Date: Thu, 10 Apr 2003 18:50:02 -0400
Message-ID: <7334.1050015002@sss.pgh.pa.us> (raw)
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@rh1 tmp]$ time psql -c "\copy foo to 'foo2'" regression
real 0m16.592s
user 0m0.521s
sys 0m0.270s
[tgl@rh1 tmp]$ time psql -c "\copy foo from 'foo3'" regression
real 0m20.032s
user 0m2.223s
sys 0m0.217s
With SSL:
[tgl@rh1 tmp]$ time psql -c "\copy foo to 'foo2'" -h localhost regression
real 4m18.912s
user 2m30.842s
sys 1m4.076s
[tgl@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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: Speed of SSL connections; cost of renegotiation
In-Reply-To: <7334.1050015002@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox