Netty and the JVM meet OpenSSL to speed up connections

5f5.org

39 points·vikrum··6 comments

I put this blog post together in the hopes that someone can benefit from the niche optimization that we undertook. Finding anything relating to "java", "ssl", and "optimizations" on a search engine along this vein is difficult to say the least.

Thanks so much for writing this up! I've been looking for a Java implementation of DTLS, and haven't found one. Since OpenSSL supports DTLS, I might be able to abuse this into doing what I need.

I'll probably want to strip down the tomcat-native dependency, but this puts me a lot closer to my goal than I was previously.

What's the benefit of doing SSL/TLS in the application instead of using a dedicated terminator like stud?

We did use stud for a short time but have recently moved back to this approach for a couple of reasons:

+ Currently out SSL connections need to be pinned to a specific server, so we wound up running the terminator on the same box. We then ran into a problem of having more than 65k connections (src ip/port <-> dest ip/port) on loopback, which introduced a bit more complexity in our deployment (either have stud use 127.0.0.2, 127.0.0.3, etc or have stud point to a different port.)

+ The memory consumption also goes up across the board since we are on the same box (2x the connections per actual connection). stud uses an additional ~200k per connection and on some of our boxes that have 100k+ connections, this is something north of 18GB. This was the biggest driver for the change.

How did you spot the loopback port bottleneck?

Seems like it'd be fairly obvious. stud should be reporting bind() failures once it runs out of port pairs.

Reply on news.ycombinator.com