7

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?

Community
  • 1
  • 1
Greg Soltis
  • 1,434
  • 9
  • 10

2 Answers2

6

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

W.Azhar
  • 61
  • 1
  • 4
4

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

Norman Maurer
  • 23,104
  • 2
  • 33
  • 31
  • 4
    Java's SSL implementation is known to be slow?Where is a backing reference for this? – Cratylus Oct 16 '12 at 20:45
  • 2
    Maybe I should be more clear.. its "slow" compared to openssl. This is also one reason why tomcat use its native providers for openssl if it can be found... Thanks for the comments and remind me to make it more clear and add another link. – Norman Maurer Oct 17 '12 at 05:41