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

[Morgan Segalis]

All this discussion made me think…

It cannot be possible that this difference between C++ and Erlang is coming from SSL.
Like said Per, It may not be 100% C++, but slightly different only.
Ok the ciphers might be responsible for a little lag, but here I'm using the same on C++ and Erlang :

AES256-SHA

And I spotted something.
While my 10K test, I'm trying to connect manually, like I wrote in my first email.

openssl s_client -ssl3 -ign_eof -connect myserver:4242

When it is very long (one of the 3 cases)… the  "CONNECTED(00000003)" 
that should appear between the connection and the handshake, does not.

I'm sorry to realize that only now, but that means that it is not the SSL handshake that takes time, but really the connection itself.

I'm not really sure where it could come from, but i'm starting to think that it may come from something like the max open file possible in erlang, or something like that…

Le 11 avr. 2012 à 10:53, Ingela Andin a écrit :

> 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