There are all sorts of kernel tuning parameters under /proc that can make a big difference, not to mention what type of virtual NIC you have in the VM. Are they running the same kernel version and Gentoo release? Have you compared sysctl.conf (or whatever gento uses to customize settings in /proc)?
Generally I prefer to run haproxy (and only haproxy) in 1 CPU vms (less CPUs, lower latency from the vm scheduler), with haproxy, my only exception is if I also want ssl and load is higher. When dealing with high rates and larger number of connections make sure you don't go low on RAM. Haproxy goes exponentially worse as it starts to swap, in fact running swapoff -a isn't a bad idea, especially for bench testing... and it takes a lot more ram to support 8000 connections/sec than 300. In summary, check RAM, and /proc tuning. > -----Original Message----- > From: Matt Banks [mailto:[email protected]] > Sent: Friday, January 13, 2012 2:40 PM > To: [email protected] > Subject: VM vs bare metal and threading > > All, > > I'm not sure what the issue is here, but I wanted to know if there was an > easy explanation for this. > > We've been doing some load testing of HAProxy and have found the following: > > HAProxy (both 1.4.15 and 1.4.19 builds) running under Gentoo in a 2 vCPU VM > (Vsphere 4.x) running on a box with a Xeon x5675 (3.06 GHz current gen > Westmere) maxes out (starts throwing 50x errors) at around a session rate > of 3500. > > However, copies of the same binaries pointed at the same backend servers on > a Gentoo box (bare metal) with 2x E5405 (2.00GHz - Q4,2007 launch) top out > at a session rate of around 8000 - at which point the back end servers > start to fall over. And that HAProxy machine is doing LOTS of other things > at the same time. > > Here's the reason for the query: We're not sure why, but the bare metal box > seems to be balancing the load better across cpu's. (We're using the same > config file, so nbproc is set to 1 for both setups). Most of our HAProxy > setups aren't really getting hit hard enough to tell if multiple CPU's are > being used or not as their session rates typically stay around 300-400. > > We know it's not virtualization in general because we have a virtual > machine in the production version of this system that achieves higher > numbers on lesser hardware. > > Just wondering if there is somewhere we should start looking. > > TIA. > matt
