Hi, On Thu, Mar 10, 2011 at 07:40:23PM +0530, Paras Fadte wrote: > Hi , > > I had a query regarding number of conn/sec in Haproxy and with regards to it > following are the details > > *Setup* > > Machine : Dual core AMD Opteron(tm) Processor 246 > Mem:8GB > OS: Ubuntu 2.6.32-24-server x86_64 GNU/Linux > > Request flow: HAProxy -> Varnish -> lighttpd ( All are running on same > machine ) > > Haproxy is running on port 2000 , varnish on 2001 and lighty on 2002 > > Benchmarking tool : Httperf > > Requested object is of size 43 bytes > > httperf --server=x.com --uri=/x.gif --port=2000 --rate=14000 > --num-conns=900000 --num-calls=1 > > Specifying HAproxy port for benchmarking shows max conn/sec average of 8600 > ( httperf shows Errors: total 341739 client-timo 0 socket-timo 0 connrefused > 0 connreset 0 > Errors: fd-unavail 341739 addrunavail 0 ftab-full 0 other 0 ) whereas > specifying varnish and lighty ports show average conn/sec very close to 14k > with no such errors. > > Is this problem with HAproxy setting ? How can the conn/sec for HAproxy be > bumped up to what varnish/lighty achieved in test results .
Well, first, the more components you chain on the same machine, the less performance you'll see. The connection rate limit is not per-component but per system. Both 8600 and 14000 seem quite low for such a machine, please check you're not using nf_conntrack. Also, please check "vmstat 1" and "top -d 1" to see how the CPU usage is distributed (user, system, I/O, softirq, ...). It is also very possible that the processes are competing for CPU. You should try to bind each of them to a distinct core to ensure this does not happen. The fd-unavail errors are quite concerning. Maybe something is wrong with your system tuning. Check /proc/sys/fs/file-max for instance. You can add "option tcp-smart-accept" and "option tcp-smart-connect" to save a few network packets. If you see a performance improvement (even minor) with this, it means the system is the bottleneck. Regards, Willy
