Hi Mark, Apologies for the late reply on this, but I was the person that asked you this performance question at ApacheCon. We reviewed this thread and appreciate the analysis and discussion. The description below is accurate; we have short lived non-keep-alived clients, so we're keenly interested in the performance of the asymmetric/handshake piece of TLS.
Obviously we could use some different architectural strategies to help improve performance, but we appreciate the raw numbers because they help with our design work. Of particular interest were the "better" numbers (1,900 TPS) provided by Rémy, as that number is certainly better than the initial example of 23 TPS. I understand that was a quick test on Mark's laptop; relative performance is what was interesting. Our own benchmarking lies somewhere between the two numbers, closer to 1,000 TPS on Tomcat 6.x (yes, I know) on one of our test servers. As noted by those here, keep-alives significantly improve performance. We're currently working through the process of moving to 8.5 with OpenSSL, so hopefully we'll be able to post back with some results in the near future. -- Thanks, Jeff On 2017-05-18 07:47 (-0600), Mark Thomas <m...@apache.org> wrote: > 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 happens if you negotiate a NULL cipher for instance? Or, perform> > > the TLS handshake but never make an HTTP request after connecting? I> > > don't know of a tool that can do that out of the box (e.g. ab makes> > > HTTP requests, not just TLS connections) but one could be written in> > > Java fairly easily.> > > > > >> test.txt is a 3 byte text file.> > >>> > >> The results were: JSSE: 17 reqs/sec OpenSSL: 23 reqs/sec> > >>> > >> So around a 35% increase.> > > > > > I'd like to see a NULL or very low-overhead cipher under the same> > > circumstances.> > > The test was with Tomcat trunk and the test keystore from the Tomcat PMC > > private repo so you should be able to set up those tests pretty quickly. > > (I did it in around 30 mins which incuded building tc-native).> > > Mark> > > > > > >> YMMV with different versions of TLS and associated ciphers, JREs,> > >> OpenSSl versions etc. >> > > Noted. ;)> > > > > > - -chris> > > -----BEGIN PGP SIGNATURE-----> > > Comment: GPGTools - http://gpgtools.org> > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/> > > > > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkdK1IACgkQHPApP6U8> > > pFhfQw/+NGm1CNQcFZ2qVzlCZ36W+TXhaKaBcWeiSCKw60jf/utEFycONRldm5Q3> > > cRM7Nbrfx1GcPwAs8ufedOtHgsAfzp6JkpzqwVFqZjUX1GODbJhz1vaNgQgB3mL8> > > YlGBoLqQIRKvQNOcTYJx5bP+tbnqARu96uINH16rMT+GQUF9nIzk+ua7ec0Goe+e> > > 6yO6euDrkV75uOMPArBWDDToSrQVZ9QKiliqlcYpnG2IPDMu1CGWDHZtwO1pxaLG> > > aMbtqea9gAj42rw3NpFjUNxqYdN4EJHhCFjIIdVCAbiqs5BZQQAjcWjaRPniq45M> > > ySsuBLNFqPj2sltlhZrdg7CEklvDbVvVgVIWZA21pw0wyfIofZnsiy+KsLo8q/wD> > > gHcOF/TkQ4pAYGVoP+wh5AnQHwze2SFTJq0RE7kE0s6cohtfXeNSH/Ga6lzbJW5d> > > B+vHpU8+U6X1Lpha8Hg0A1KxbP7hcANfdLTiRqZNIVMQES8p6Zh+fbIX+DlVYIFR> > > WLFNmFADdlZ5msxHwRjfdQ8dtL6McwyvM3kmDQeADU/YzN80bhXmr8ZHJJUevTUJ> > > cya5zcw5MmPrzdlavXhH0VKspbprPoJxrd9llRU0ra5aNfUmJ4xA79jD5VxQmNL/> > > Cglw5DT8QoxG3knjZEQ8YLRj0gq0NrQXQmzowxqekfMcyNc2EGg=> > > =+yjT> > > -----END PGP SIGNATURE-----> > > > > > ---------------------------------------------------------------------> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org> > > For additional commands, e-mail: users-h...@tomcat.apache.org> > > > > > > ---------------------------------------------------------------------> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org> > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
