Hi, On Tue, Jan 06, 2009 at 08:14:33AM +0530, Angsuman Chakraborty wrote: > Hi, > > I am looking at nginx (as a proxy) and haproxy to setup a cluster of > machine to serve WordPress blogs. Initially I was going with nginx but > the biggest problem with nginx is that I have no way to limit the number > connection to a machine (even with fair load balancer) which haproxy > does. This is a big issue with apache servers because 3 out of 4 > machines appears to hang with heavy spike loads, requiring manual > restarts (any input on this issue would be appreciated though I > understand it is not the right forum for this). > > Haproxy works like a champ by protecting the server. However I expected > it to queue the requests in its global queue. It didn't seem to happen > that way as per the stats console.
It queues anonymous requests in its global queue, and sticky requests in the servers' queues. > 1. Why *isn't haproxy queuing the requests*? What parameters should I > tweak to queue requests upto a reasonable level? I see an error in your configuration. Almost all your servers have the same cookie, so only the first one will get the sticky requests. I suppose it's the one whose queue is huge in the stats ! > The biggest problem I am having is that the throughput is much lower > than that of nginx. * It's not expected (although nginx is fast too). Maybe this is simply because all your requests go to the first server, which becomes the bottleneck ? > 2. What can we do to improve the overall throughput* *of haproxy*? It depends on what throughput you need. Do you need large numbers of hits per second, large bit rate ? Right now, to go above 1 Gbps or above about 5-10000 requests/second, you need quite some fine system tweaking. I don't know the level of limits you are currently observing. > My haproxy configuration is: > global > log 127.0.0.1 local0 > log 127.0.0.1 local1 notice > maxconn 32000 > chroot /usr/share/haproxy > uid 99 > gid 99 > ulimit-n 65536 > daemon > nopoll > > defaults > log global > stats enable > mode http > option httplog > option dontlognull > retries 3 > option redispatch > maxconn 2408 > contimeout 30000 > clitimeout 60000 > srvtimeout 30000 > timeout connect 10000 > > listen nginx-pool 172.16.0.66:80 > option httpchk GET /test > balance leastconn > server fighter 172.16.0.74:80 cookie fighter weight 2 minconn > 25 maxconn 75 check inter 30000 maxqueue 200 > server workhorse 172.16.0.50:80 cookie fighter weight 4 minconn > 30 maxconn 100 check inter 30000 maxqueue 400 > server testing 172.16.0.53:80 cookie fighter weight 4 minconn > 30 maxconn 100 check inter 30000 maxqueue 400 > server apollo 172.16.0.73:80 cookie fighter weight 3 minconn 30 > maxconn 100 check inter 30000 maxqueue 300 > server margay 172.16.0.61:80 cookie margay weight 1 minconn 20 > maxconn 75 check inter 30000 maxqueue 100 > > 3. *Is sepoll better than epoll for Linux 2.6.x kernel*? I am using > Fedora 8 distro. yes, sepoll is better than epoll because we can avoid a lot of polling, especially when the servers respond quickly. If you need very fast data rates, the work I'm currently doing at integrating support for kernel 2.6's splice() (and fixing it in the kernel since it's buggy) will help a lot. It's not that hard to reach 10 Gbps with it on a recent machine, but the kernel needs much fixing right now. So stay tuned ! Regards, willy
