添加链接
link之家
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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?

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

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

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, 2012 at 5:41

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question . Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .