[erlang-questions] New ssl vs Google Chrome

[Ingela Andin]

Hi!

We will have to look into this more, as a start see comments below:

2012/3/7, Per Hedeland <per@REDACTED>:
> Hello,
>
> Is anyone else seeing (or even better, fixing:-) performance problems
> when Chrome is used towards a HTTPS server with "new ssl"? With the
> server running on a "pretty slow" PPC system, I'm seeing a simple test
> (connect and log in to webui) where beam + ssl_esock used a total of ~ 1
> second CPU with "old ssl" (in R14B01) use upwards of 12 seconds CPU with
> "new" (still R14B01) - i.e. essentially unusable.
>
> Running ssldump reveals that Chrome's SSL behavior is pretty braindead
> (a technical term) - it opens loads of SSL connections, most of them
> without session reuse, and if it's unhappy with the server cert it will
> also close most of them without even completing the client side of the
> handshake, let alone doing any application data transfer.
>
> The test used a cert with a 4096 bit RSA key - dropping it to 1024 makes
> the problem basically go away (~ 0.4 second CPU with "new"). This would
> seem to confirm that the bad performance is due to the many full
> handshakes generated by Chrome - but it's obviously not a fix, nor does
> it explain the huge difference between old and new (the Chrome behavior
> is basically the same with both).
>
> I tried doing just the RSA signing with a 4096 bit key on the "pretty
> slow" system - via public_key it uses ~ 1.4 seconds CPU, "directly" with
> libcrypto ~ 0.5 seconds. This seems rather strange, since as far as I
> can see there isn't much code executed besides the libcrypto call when
> public_key is used.

crypto:mpint/1 ofcourse is an overhad that could somehow be worked out
of the equation.
I tried it with a big key on my machine but does not appear to make such a big
difference that it does for you.

> And there still remains an unexplained factor of 4
> or more in lost performance.

Does your server do client verification? If crypto:mpint/1 is an issue
you would get a few more of those in that case.

> The performance seems to have improved a bit in R14B04, with 6 seconds
> CPU for the above test - but it's still not really usable, and I don't
> see anything relevant in the READMEs. I should add that the comparison
> above also used different versions of yaws, 1.62 vs 1.91 - but it's hard
> to see how this could have a significant impact on the SSL handshake.
>
> Any info appreciated...
>
> Thanks
>
> --Per Hedeland
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>

Regards Ingela Erlang/OTP team - Ericsson AB