> -----Original Message----- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Thursday, May 18, 2017 8:47 AM > To: users@tomcat.apache.org > Subject: Re: TLS handshake performance > > This time to the right list... > > On 18/05/2017 06:04, Christopher Schultz wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Mark, > > > > On 5/17/17 5:31 PM, Mark Thomas wrote: > >> I got asked in the corridor at TomcatCon earlier today what the > >> relative performance of the TLS handshake was with 8.5.x, the NIO > >> connector and JSSE vs OpenSSL TLS implementation. > > I'm curious about what exactly "TLS handshake" was intended to mean > > (by the person who asked the question) in this context. > > They are using Tomcat in a scenario where clients are making single requests > (so keep alve doesn't help). Given that the handshake uses asymmetric > encryption which is more expensive that symmetric encryption (which is why > the handshake is used to establish a shared secret so symmetric encryption > can used for the actual data) they wanted a sense of the performance > benefit - if any - of NIO and 8.5.x with OpenSSL vs NIO and 8.5.x with JSSE. > > > The handshake itself does not perform any bulk transfer of encrypted > > data, so the negotiated cipher suite does not matter. However... > > > >> Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z > >> ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt > > > > Here the cipher suite matters very much, since the client is not only > > performing the TLS handshake but also transferring the client's > > request to the server and the server's response back to the client. > > > Support for a particular algorithm may dominate the benchmark, here. > > Agreed. But it is the handshake that dominates the timings (if you add -k to > use keep-alive the req/sec are an order of magnitude higher). > > The cipher suite was the default one chosen by by one of the configs (I > forget which). > > The cipher suite will affect the results since it also impacts the enctrpyion > used during the handshake but for any 'reaosnably' secure cipher suite, I'd > expect similar results in terms of the relative performance. >
What about SSL session reuse? Did you have any way of disabling that? If you're testing against a single server, you'll get 100% reuse, which makes a big difference in the CPU load (lower) on the server. If your real world case involves dozens or hundreds of servers behind a load balancer, you get almost no reuse. Thanks
