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

Morgan Segalis <>
Tue Apr 10 23:48:43 CEST 2012


Hi Max, 

Yes, the C++ code and the Erlang code, are running on the same server.

Le 10 avr. 2012 à 23:35, Max Bourinov a écrit :

> Hi Morgan,
> 
> Did you try your tests on the same machine?
> 
> Sent from my iPhone
> 
> On 11.04.2012, at 1:21, Morgan Segalis <> wrote:
> 
>> 
>> Le 10 avr. 2012 à 22:39, Per Hedeland a écrit :
>> 
>>> SEGALIS Morgan <> 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
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list