Hi Gary, On Thu, Jan 07, 2016 at 09:48:59PM -0800, Gary Barrueto wrote: > I've been testing ssl with version 1.5.14 and 1.6.3. I noticed that with > larger files (1mb) reqs/sec is on average 7% slower and as much as 16% > depending on the cipher when using version 1.6.3 compared to 1.5.14. > Smaller requests (4k files) are not affected. Haproxy is using the exact > same config for each version and is using nginx on localhost to serve the > static files. We're getting our stats from running wrk benchmark tool > ??? ??? > which is running from another server with the same hardware spec which is > connected on the same switch. > ??? ??? > Any ideas what may be causing this?
Unfortunately not. Do you have a way to ensure the same algorithms are negociated on both versions ? I've run a diff between 1.5.14 and 1.6.3 regarding SSL, and it's very limited. Most of the changes affect OpenSSL 1.0.2 (you're on 1.0.1), or automatic DH params and in your case they're already forced. There's something though, I'm seeing SSL_MODE_SMALL_BUFFERS being added in 1.6. It only comes with a patch and is not standard, it allows openssl to use less memory for small messages. Could you please run the following command to see what SSL_MODE_* options are defined on your system : $ grep -rF SSL_MODE_ /usr/include/openssl/ > I have the 'haproxy -vv' output and hardware specs listed below. Also > attaching the haproxy/nginx configs being used. Thank you, I'm really not seeing anything suspicious there. There's something that you should definitely do if you're running on a kernel 3.9 or later, which is to use as many "bind" lines per frontend as you have processes. That makes use of the kernel's SO_REUSEPORT mechanism to balance the load across all processes much more evenly than when there's a single queue. It might be possible that your load is imbalanced right now. > Other then that version 1.6.3 seems to be preforming well on smaller > requests. Its the larger requests we're worried about as thats the size of > the majority of the traffic we want on ssl. That's what puzzles me. Usually the SSL performance issues are more visible on small objects than large ones because they're caused by larger keys or more costly protocols. Here it would imply either more buffer exchnages, or more expensive symmetric crypto. Just out of curiosity, what is the order of magnitude of the numbers you're observing ? Regards, willy
