Slow Java SSL in a netty application

Question

I'm experiencing a significant performance degradation using netty's SslHandler vs an external SSL terminator like stud or stunnel. The difference is about 100ms in time to complete the handshake. I requested the same resource from my application several hundred times via httperf and made sure that the same cipher (DHE-RSA-AES128-SHA) was used in each case.

This question got no accepted answers, but the comments indicated that running an SSL terminator in front of a Java process might be a good idea.

Is this expected behavior? Is Java's SSL implementation known to be this much slower, or is it possible that I have some setting configured improperly?

Answer 1

Netty folks recommend openssl over JDK SSL for couple of reasons, performance is one of them. Explanation can be found on their wiki:

http://netty.io/wiki/requirements-for-4.x.html#benefits-of-using-openssl

Answer 2

Yeah it's known to be slow, compared to openssl,.. You could try to use native openssl bindings like twitter does:

https://github.com/twitter/finagle/tree/master/finagle-native

This is one reason for apr and SSL:

http://tomcat.apache.org/tomcat-6.0-doc/apr.html#HTTPS