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

[Morgan Segalis]

Le 10 avr. 2012 à 22:39, Per Hedeland a écrit :

> 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

Hi Per,

Thank you for have taking the time to write this clear answer.
Actually I'm kinda desperate.
I found very weird indeed that there is so much differences between Erlang and C++
But I really can't think about anything else,
I'm having multiple acceptor at once, set the Erl shell running on 8 threads…
Even changed the ciphers to almost every possible options.

The fact is in C++ I launch a thread after each socket accepted, and does the handshake on the said thread.

It seems that "Learn You some Erlang" implementation is the best for what I'm trying to do. If not please anyone tell me what should I change.

What could limit so much the connection if it is not SSL, really ?