Re: Running haproxy on the cluster nodes

Hi Martin,

On Tue, Dec 11, 2007 at 08:28:49AM -0500, Martin Goldman wrote:
> Thanks Willy, I better understand what you're saying now. I checked and
> don't have the ip_conntrack module on my systems.

OK, that's fine.

> I ran haproxy with -V and
> re-ran the same test, and the only output I got was what's below. I'm on
> 1.3.13.1 but can upgrade to the newest version if that would be helpful.

That's not required. It would provide you with new shiny features but possibly you don't need them anyway.

> Just in case there's something outrageously wrong with my config, I'm
> pasting that below too -- FYI, I removed a few things (such as logging) and
> the performance improved somewhat, but is still worse than that of the
> individual web servers. Please let me know if you have any other ideas.
> Thanks for all the help!
>
> martin#kramer:~$ sudo /usr/sbin/haproxy -V -f /etc/haproxy.cfg
> Available polling systems :
> poll : pref=200, test result OK
> select : pref=150, test result OK
> Total: 2 (2 usable), will use poll.
> Using poll() as the polling mechanism.

OK, HERE is the problem: you are using poll. I think you compiled your haproxy with the default "generic" target, which is portable but not much optimized. You should use epoll() on kerner 2.6, as its CPU usage doesn't vary with the number of concurrent connections. In order to do this, just build like this :

  $ make clean
  $ make TARGET=linux26

Then restart with -V to ensure that it correctly uses epoll() (or sepoll which is epoll relying on speculative I/O), and you should be fine.

I see no maxconn in your config below. By default, I think the maxconn is somewhere around 1000 or 2000, I don't remember (because I don't use the default one). You should specify it, both in the global section and in the listen section. If your maxconn is too low, the client connections will wait for the socket in the system's queues first, then will be dropped when the queues are full. So it is very important that you set it.

Also, you can (and should) set a per-server maxconn to slightly less than the MaxClients you configured on your apache processes. This will ensure that an apache server will never get overloaded. Excess connections will simply be queued or sent to the remaining available server(s).

Otherwise, I see nothing wrong.

Regards,
Willy Received on 2007/12/11 20:06