Speed of SSL connections; cost of renegotiation

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