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

[Ingela Andin]

Hi!

Of course we need to continue investigating this, as for the patch
that Per is talking about  see comment below.

2012/4/10 Per Hedeland <per@REDACTED>:
> 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.

I am not in a position to make any promises, but it is a fairly easy
patch and the plan is to include it for R15B02.  We did not want to
try and force it in to R15B01 after the deadline. Late fixes are
seldom a good idea even when they feel trivial.

> 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.)

There are lots of gains doing things in Erlang instead of C/C++.
Eaiser to maintain, portable, quicker to implement new features, can
gain multicore benefits etc.  Even though C/C++ will be faster for the
small sequential-benchmarks it is far from certain it will be the
quickest in the bigger picture parallell world.  I will continue
investegation your findings  to see if there are any improvments we
can make to erlang-ssl.

Regards Ingela Erlang/OTP team - Ericsson AB