

Netty and the JVM meet OpenSSL to speed up connections - vikrum
http://5f5.org/ruminations/netty-meets-openssl.html

======
vikrum
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.

~~~
kelnos
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.

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

~~~
vikrum
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.

~~~
cagenut
How did you spot the loopback port bottleneck?

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

