Hi Jens-Christian, On Wed, Jan 29, 2014 at 02:04:50PM +0100, Jens-Christian Fischer wrote: > Hi all > > I'm fairly new to HAProxy so I might have done something amazingly stupid?. > > I have HAProxy 1.5-dev19 (and now dev21) setup to terminate SSL and forward > requests to 3 nginx/php5-fpm servers that run a heavy PHP application?. > > I have run a number of benchmarks against HAproxy with and without SSL and > see the following results: > > benchmark commands: > ab -c 1 -n 500 "http://example.com/status.php"; > ab -c 1 -n 500 "https://example.com/status.php"; > > where -c is the concurrency level, and -n the number of requests. /status.php > is a script that loads the complete PHP stack of the app and returns a tiny > html file (12 bytes) with the status > > > HAproxy and the VMs are running on virtual machines in an OpenStack cluster, > the benchmarks were performed from one of the physical hosts of that cluster: > > Latency between benchmark host and HAProxy VM: > ping example.com > PING st-fl-1.2.3.4.example.com (1.2.34) 56(84) bytes of data. > 64 bytes from st-fl-1.2.3.4.example.com (1.2.34: icmp_req=1 ttl=63 time=0.919 > ms > 64 bytes from st-fl-1.2.3.4.example.com (1.2.34: icmp_req=2 ttl=63 time=0.858 > ms
That ping time already sounds huge for a local network. Seems like a 10 Mbps network. I get 147 microseconds when pinging an ALIX that sits on my desk and that is connected at 100 Mbps to the local switch. > I vary concurrency level and get the following mean response times per > request: > > HTTP:-c 1 -n 500: 54.800 [ms] > SSL: -c 1 -n 500: 64.467 Huh! Could you check the application directly first to confirm that the 54 ms are the expected response time ? The SSL handshake adds some round trips, so given your network latency, it can explain why it adds 10ms (though that would mean 10 round trips) over HTTP. > HTTP: -c2 -n 500: 57.696 ms > SSL: -c2 -n 500: 70.699 ms > > HTTP: -c4 -n 500: 61.966 ms > SSL: -c4 -n 500: 77.379 ms > > HTTP: -c 8 -n 500: 64.711 ms > SSL: -c 8 -n 500: 92.793 ms > > HTTP: -c 16 -n 1000: 63.882 ms (doubled the number of request to account for > more concurrency) > SSL: -c 16 -n 1000: 118.347 ms > > HTTP: -c 32 -n 1000: 74.488 ms > SSL: -c 32 -n 1000: 172.178 ms > > HTTP: -c 64 -n 1000: 133.784 ms > SSL: -c 64 -n 1000: 317.118 ms > > HTTP: -c 128 -n 2000: 261.037 ms > SSL: -c 128 -n 2000: 528.435 ms These response times are absolutely ugly and not usable at all. For sure something is broken. > Using a "hello world" php file (<?php echo "Hello World"; ?> ) I see that > this setup can do around 2500 - 3000 requests / second with HTTP and around > 200 requests / second with SSL That's indeed abnormally slow. And I can't imagine the latency with these numbers! Could you please run ab from the haproxy machine to the PHP server to get a reference of this direction ? It will also tell you what part of the response time the network represents. Also you can try with ab -k in a second test (keep-alive) which will save you from connection setup times. It will save two round trips per request, one of which appears in the measure. On a sane local server, you should almost not notice the difference. Here I already expect a difference. > Are these numbers something that is expected? should HAProxy be able to > terminate more than 200 SSL requests per second? Clearly not, your numbers should be at least 10-100 times that. That smells like the usual VM environment running on an overbooked system capable of running 8 VM and sold to run 200. > Here's the haproxy.conf file: (...) Your configuration is fine and clean. You should definitely get much better numbers. Recently one guy posted so ugly results on the list when running in a virtualized environment, and moving to a sane place got rid of all his trouble. The only thing I like with these dishonnest people selling overloaded VMs is that they make us spread load balancers where none should be needed if what they sold was what they advertise! Regards, Willy
