Willy TARREAU 刚发布了1.3.9版本的haproxy, 支持FreeBSD kqueue；为支持FreeBSD kqueue，event处理机制也全面改进（机制类似lighty）。在阅读代码后，我可下个结论：Haproxy里最后一块“古老的”、“落后的“代码顽疾也消除了，部署HAproxy的最后障碍也烟消云散了。
作者对haproxy 1.3.9做了最新的Benchmark，硬件是单核P4 CPU，PCI Express Gigabit网卡，效果非常好。
HAproxy 用rbtree替换原来doule linked list做task后，还是经常出现使用率100%的情况，不解。用gdb跟踪发现CPU 100％时，haproxy经常在src/fd.c的epoll_loop()函数，照理epoll这种notify机制，不大可能耗时很多。然后细看函数，不看不知道，一看下一跳，omg，epoll_loop()居然有大循环，完全违背了epoll的理念。估计是作者从select->poll->epoll 升级过程中，没怎么改系统结构，导致效率低下，汗。有空操刀改之
haproxy 1.3.4 今天发布了，最大的改变是"Content-Switching"。frontend根据任意HTTP请求头内容做规则匹配，然后把请求定向到相关的backend；frontend和backend是1.3.4引入的新概念。加了这个功能的Haproxy，和硬件的Level 4 Switch功能上基本差不多了，赞！
举例：
frontend public #frontend，等于以前的listen main 192.168.1.10:80
bind 192.168.1.10:80
mode http
log global
option httplog
option dontlognull
option httpclose
monitor-uri /monitoruri
maxconn 8000
clitimeout 30000
# Host: will use a specific keyword soon
reqisetbe ^Host:\ img static #类似打补丁scaner后的reqigo
# The URI will use a specific keyword soon
reqisetbe ^[^\ ]*\ /(img|css)/ static
reqisetbe ^[^\ ]*\ /admin/stats stats
default_backend dynamic
Haproxy处理HTTP请求的流程更清晰了
一直对服务器、软件的性能优化很有兴趣：从用squid做缓存到编写mod_cache做缓存；从用LVS到用haproxy做负载均衡，都是自发的。昨天在3台P4D 4G内存服务器上部署图片缓存，发现haproxy 经常check 后面的lighttpd失败；而相同配置在两台Xeon 4G内存服务器上没任何问题。折腾1个小时把haproxy的配置按不同域名分配3台服务器，调整不同的httpclose参数，调整lighttpd的配置，取得很好的效果，haproxy check 后面lighttpd都ok。
今天知晓某部门正在采购双CORE 2 DUO CPU，每CPU有4核，再配16G内存的服务器来支撑更大负载。呵呵，硬件的发展已经大大超越了软件的进步，与其耗费人力物力改进软件，还不如买更牛X服务器来的快、轻松。软件优化可以休矣，Xeon P4D靠边站，让C2D来得更猛烈些吧！
最近在寻找LVS的替代程序，加上scaner同学的忽悠，我也开始用先进科技haproxy。haproxy表现很不错：支持的并发连接上万没问题；流量上几百M也没问题，出乎意料；更赞的是HAProxy有详细的状况报告页面，有了报告，调优更方便了。当然HAProxy也有问题：并发连接多时CPU占用很高。
对于图片服务器，打开HTTP Keep Alive还是有帮助的：一般页面中会有N多个同一域名的图片，如果不开Keep Alive，浏览器下载图片慢。打开HTTP Keep Alive，连接数一般就会多八九倍。现有的haproxy的task_queue函数(task.c中)时间复杂度是O(n)，开销很大。作者已经在实现新的O(log(n))的task_queue，等待合适的机会发布。
lighttpd的maillist在讨论多CPU情况下lighttpd的效率，有人就提到HAProxy。HAProxy首页有段关于Keep Alive的话很好：
"Keep-alive was invented to reduce CPU usage on servers when CPUs were 100 times slower. But what is not said is that persistent connections consume a lot of memory while not being usable by anybody except the client who openned them. Today in 2006, CPUs are very cheap and memory is still limited to a few gigabytes by the architecture or the price. If a site needs keep-alive, there is a real problem. Highly loaded sites often disable keep-alive to support the maximum number of simultaneous clients."