[erlang-questions] Erlang accepting SSL connection is really slow (comparing to C++)

[Per Hedeland]

SEGALIS Morgan <msegalis@REDACTED> wrote:
>
>While it will take 10 second to a ssl accepting bit of C++ code to accept
>all of them (which don't even have multiple accept pending), in Erlang this
>is quite different. It will accept at most 20 connections a second
>(according to netstat info, whilst C++ accept more like 1K connection per
>seconds)

As has already been pointed out, a) the DH-based cipher suites make for
a very slow (mainly due to high CPU usage) handshake, and b) you need to
check the selected cipher in your benchmarking to determine if one of
these is being used. If you don't see any difference when disabling
them, have you verified that they aren't being used? (I.e. maybe you are
doing a mistake when disabling...)

I'd just like to point out that the current OTP ssl implementation may
end up using one of the DH-based suites "by default", while typical
C/C++ + OpenSSL implementations (including the "old" ssl_esock-based OTP
implementation) will not, since it requires a bit of extra work to make
OpenSSL use them.

Another reason for the handshake slowness, if you are using a
suite/certificate with RSA authentication (pretty much the norm), is
that the RSA signing operation is some 3-4 times slower than it need be
with the current OTP ssl implementation. I reported this in
http://erlang.org/pipermail/erlang-questions/2012-March/064925.html and
subsequently found the cause, which is that a number of private key
parameters aren't used even though they are available - to quote the
OpenSSL rsa(3) man page:

    p, q, dmp1, dmq1 and iqmp may be NULL in private keys, but the RSA
    operations are much faster when these values are available.

- "much" is an understatement I think.:-)

I've recently submitted an "informal" patch fixing this to the OTP
group, Ingela may be able to comment (or not:-) on when it might make it
into the release. If you're desperate I can provide the patch off-list,
it's not overly complex. But this issue alone can definitely not explain
the difference you are seeing.

Finally I'll point out that while the SSL protocol implementation is
indeed implemented in Erlang now, all the "heavy crypto work" is still
done in OpenSSL's libcrypto, with a "thin" NIF interface in between. The
net result is probably a bit slower than 100% C/C++, but it shouldn't
(need to) be anywhere near what you report. (The good part is, of
course, that the implementation can make use of the Erlang/beam
concurrency support, instead of the hairy pthread stuff you need to use
for OpenSSL's libssl.)

--Per Hedeland