On Thu, Aug 16, 2012 at 01:43:50PM -0400, Saul Waizer wrote: > Well, it turns out it was the "option httpclose" that was set on the > defaults > > I commented out both httpclose and http-server-close and I got the desired > throughput, 2k+ req/sec, then I enabled http-server-close and ran the test > again and still got the desired throughput, enabling httpclose made it go > down to 100 req/sec. Why would this cause such behavior though?
it may be many things. It's possible that you're saturating a firewall somewhere in the chain between the client and haproxy. Since we don't know if the 100 req/s is stable during the whole test or is just an average measured at the end of the test, it could very well be that you reach the total number of conns a firewall supports and have to wait for them to time out. The ratio is too high to be just a matter of virtual vs physical, because there are not *that* many extra packets, by default without tuning, you'd get 4 packets per request instead of 8. It's also possible that jmeter takes a lot of time to establish a connection, for instance because it would be designed to work with connection pools by default and would recycle closed connections inefficiently. You should vary the components you're using in order to find the issue, because quite clearly a limit of 100 req/s is extremely low, it could be handled by a watch ! Regards, Willy
