[erlang-questions] New ssl vs Google Chrome

[Per Hedeland]

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. And there still remains an unexplained factor of 4
or more in lost performance.

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