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

[Max Bourinov]

Hi Morgan,

Did you try your tests on the same machine?

Sent from my iPhone

On 11.04.2012, at 1:21, Morgan Segalis <msegalis@REDACTED> wrote:

>
> 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 ?
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions