2016-02-15 10:45 GMT+01:00 Mark Thomas <ma...@apache.org>: > Looks like such a claim is indeed over simplified. > > Having tweaking the test so the same cipher is used, NIO+JSSE is about > 10% faster than NIO+OpenSSL :( > > Enabling direct buffers didn't seem to help. >
Well, you're probably using an unoptimized cipher then. We'd need to determine the cipher(s) which should be tested. For example, with OpenSSL, ECDHE-RSA-AES256-GCM-SHA384 is fast (that's what ab connects with), while DHE-RSA-AES128-SHA256 is slow (ab connects to JSSE with that, so I forced it with -Z to compare, and OpenSSL is slightly slower than JSSE with it). With my OpenSSL, ECDHE-RSA-AES256-GCM-SHA384 is an order of magnitude faster than DHE-RSA-AES128-SHA256 (and it does sound more secure as well). JSSE doesn't have ECDHE-RSA-AES256-GCM-SHA384 however. Also my Firefox 44 refuses to handshake with JSSE with its default configuration (there: ssl_error_no_cypher_overlap) :( So as I was saying, this SSL testing is hard ;) I believe OpenSSL is much faster in the real world though (and it implements the latest security/features/etc). > > >> Last, APR is still significantly faster for me, which is rather normal. > >> It's not that critical at this performance level, probably, but it's > here > >> to stay. > > > > An in depth comparison between the three options would be useful at some > > point. > > This is definitely looking to be the case. I do wonder what role the > size of the response plays. I was using very small response bodies in my > test. If OpenSSL is faster at the encryption but comes with an overhead > then at some point, as response size increases, it should become the > better option. > I'm not convinced, I'm testing tomcat.gif so that should be small as well. > > > Have you done much performance tuning of NIO + OpenSSL? > > I'll probably take a quick look at this to see of there is anything > obvious that can be done to improve things. > > No problem. Rémy
