On 15/02/2016 08:11, Mark Thomas wrote: > On 14/02/2016 22:36, Rémy Maucherat wrote:
>> SSL tests are difficult however, what do you use ? > > The same test as I was using for JASPIC. > >> Direct buffers help >> OpenSSL a lot for example (socket.directBuffer and socket.directSslBuffer >> to true). Also one important item is to make sure the tests all use the >> same cipher, especially with ab (JSSE might not use the same cipher as >> OpenSSL), something like: ab -k -Z "AES128-GCM-SHA256" forces testing of >> this common AES-GCM cipher. Newer and more secure ciphers are often way >> slower, no surprise there. > > Good point. I'll double check that. What I was really after was a some > numbers to back up a (probably over simplified) "drop in the native > library and turo-charge your TLS performance" claim. 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. >> 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. > 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
