HAProxy

The Reliable, High Performance TCP/HTTP Load Balancer

Quick links

Quick News

Since the announcement of the Slowloris tool, people seem to be discovering how fragile a default Apache setup can be ! Well, this is not news, as people who install Apache on high-traffic sites have been aware of this weakness for ages, and have been setting very low timeouts and disabling keep-alive in order to mitigate risks. Now that a tool is publicly advertised, I'm beginning to hear questions from worried site admins about what to do if their site is attacked. Also, we're seeing several sites and forums suggesting installing HAProxy in front of Apache servers to protect them (note that Nginx would probably do equally well).

Indeed, HAProxy does not need a new thread nor process to accept a new connection, it only needs some RAM (16-32 kB per connection). Some people are already using it past 70000 concurrent connections, which cannot be achieved on Apache which needs an expensive thread or process per connection. More specifically, HAProxy will only forward complete and valid requests. This means that it will not bother Apache while the attacker is playing with its few thousands connections, and all valid requests will immediately pass through. And the icing on the cake is that HAProxy can kill requests which take too much time to complete, using timeout http-request (more than a few seconds is not to be considered normal).

Once again, we observe a derivate use of a load-balancer, which is a bit expected : when a tool is designed to accept 10 times more load than the servers it feeds, there is nothing surprizing that it can be used to protect them ! Let's see if Apache evolves towards providing more tunables to mitigate such attacks... In the mean time, a drop-in anti-DoS configuration is available here.

May 10th, 2009 : 1.3.18

Yan Qiao of Rocket Fuel Inc reported a crash on x86_64, which was pretty much unexpected ! He nicely offered to help troubleshooting by rebuilding with debugging on and leaving the process running in production to catch the error, then sent me an interesting core 1 week later, which revealed that a field in the struct session which was never touched had been changed due to the sharing of two pools of the same size. This field should have been initialized but was unfortunately not. The issue can only happen on x86_64 with HTTP logging enabled, due to the exact 1024 bytes of the struct session which allows its pool to be shared with the struct requri's. Thank you guys for your huge help and the risks you have taken leaving that process running!

During a troubleshooting session with the T20 guys (Maxim Fedchishin, Jason Coward and Viktor Brilon from modX team, Hans from RightScale team), I came across an old leftover process doing nothing after a soft-reload. That issue is brought once in a while by various people, but it happens too rarely for anyone to get an opportunity to debug it. The guys accepted that I installed a debugger on their machine to see what the process was doing. It was deadlocked in free() during the reload. And that made sense : during a reload, the old process releases as much memory as possible to leave room for the new one. If the two signals sent by the second one are too close to each other, the second signal is sent while the first one has not completed releasing memory and we can have a recursion in the libc's free(), causing a deadlock. That has been fixed by implementing asynchronous signal delivery. Thank you guys for giving me the opportunity to catch that rare event!

Problems aside, a few minor features were merged. The stats are now more readable, report max session rates and provide full 64-bit counters everywhere. It is now possible to forward invalid requests or responses without blocking them, but they will still be captured. The config parser now warns about possibly unwanted ordering of ACLs or reqxxx/rspxxx. Several wrong printf() format strings have been fixed. The build process now supports an alternative architecture, and the RPM spec file has been cleaned. A new balance hdr(header) algorithm has been added to balance depending on a header hash. A new option enables addition of the destination IP address in the X-Original-To header. And last but not least, the doc has been massively cleaned up and reorganised.

With all these fixes, I released 1.3.18, as well as 1.3.15.9 and 1.3.14.13 which are probably among the last ones of their respective branches after 12 and 18 months of maintenance.

April 19th, 2009 : new performance record broken !

It was a long time since my last 10 Gigabit tests, exactly one year. The Linux kernel has evolved a lot, so did HAProxy and even the Myri10GE driver. I knew we could get much throughput since we fixed the kernel splice() syscall. It was a good opportunity to start a new series of benchmarks again. In short, new records were broken. Full 10GbE line rate with 20% CPU, and the 100000 sessions/s barrier was crossed !

March 29th, 2009 : 1.3.17

Bart Bobrowski of who's.amung.us reported abnormal CPU usage with the new version 1.3.16. After a full day of tests and code analysis, I failed to reproduce the issue here, and the bug appeared impossible to me. Bart then offered a lot of help with testing many patches, providing hundreds of megs of traces, so that I could finally fix the issue caused by a nasty race condition. I really appreciate it when users with extreme loads accept to take traces in production, with all the risks that this practise implies. Sometimes it's the only way to get a bug fixed.Thanks Bart!.
Since other minor fixes and enhancements were pending, I released 1.3.17, which users of 1.3.16 are invited to upgrade to.

Recent news...

Latest versions

Description

HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications. It is particularly suited for web sites crawling under very high loads while needing persistence or Layer7 processing. Supporting tens of thousands of connections is clearly realistic with todays hardware. Its mode of operation makes its integration into existing architectures very easy and riskless, while still offering the possibility not to expose fragile web servers to the Net, such as below :

Currently, two major versions are supported (NB: comment is outdated):

• version 1.3 - content switching and extreme loads
  This version has brought a lot of new features and improvements over 1.2, among which content switching to select a server pool based on any request criteria, ACL to write content switching rules, wider choice of load-balancing algorithms for better integration, content inspection allowing to block unexpected protocols, transparent proxy under Linux, which allows to directly connect to the server using the client's IP address, kernel TCP splicing to forward data between the two sides without copy in order to reach multi-gigabit data rates, layered design separating sockets, TCP and HTTP processing for more robust and faster processing and easier evolutions, fast and fair scheduler allowing better QoS by assigning priorities to some tasks, session rate limiting for colocated environments, etc...
• version 1.2 - opening the way to very high traffic sites
  The same as 1.1 with some new features such as poll/epoll support for very large number of sessions, IPv6 on the client side, application cookies, hot-reconfiguration, advanced dynamic load regulation, TCP keepalive, source hash, weighted load balancing, rbtree-based scheduler, and a nice Web status page. This code is in deep feature freeze and may eventually receive critical fixes only.

Version 1.1, which has been maintaining critical sites online since 2002, is not maintained anymore. Users should upgrade to 1.2 or 1.3, keeping in mind that 1.2 will soon not be supported anymore either.

Unlike other free "cheap" load-balancing solutions, this product is only used by a few hundreds to a few thousands of people around the world, but those people run very big sites serving several millions hits and between several tens of gigabytes to several terabytes per day to hundreds of thousands of clients. They need 24x7 availability and have internal skills to risk to maintain a free software solution. Often, the solution is deployed for internal uses and I only know about it when they send me some positive feedback or when they ask for a missing feature ;-)

Design Choices and history

It began in 1996 when I wrote Webroute, a very simple HTTP proxy able to set up a modem access. But its multi-process model cloberred its performance for other usages than home access. Two years later, in 1998, I wrote the event-driven ZProx, used to compress TCP traffic to accelerate modem lines. It was when I first understood the difficulty of event-driven models. In 2000, while benchmarking a buggy application, I heavily modified ZProx to introduce a very dirty support for HTTP header rewriting. HAProxy's ancestor was born. First versions did not perform the load-balancing themselves, but it quickly proved necessary.

Now in 2009, the core engine is reliable and very robust. Event-driven programs are robust and fragile at the same time : their code needs very careful changes, but the resulting executable handles high loads and supports attacks without ever failing. It is the reason why HAProxy only supports a fine set of features. HAProxy has never ever crashed in a production environment. This is something people are not used to nowadays, because the most common things new users tell me is that they're amazed it has never crashed ;-)

People often ask for SSL and Keep-Alive support. Both features will complicate the code and render it fragile for several releases. By the way, both features have a negative impact on performance :

• Having SSL in the load balancer itself means that it becomes the bottleneck. When the load balancer's CPU is saturated, the overall response times will increase and the only solution will be to multiply the load balancer with another load balancer in front of them. the only scalable solution is to have an SSL/Cache layer between the clients and the load balancer. Anyway for small sites it still makes sense to embed SSL, and it's currently being studied. There has been some work on the CyaSSL library to ease integration with HAProxy, as it appears to be the only one out there to let you manage your memory yourself.
• 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 2009, 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. The real downside of not having keep-alive is a slightly increased latency to fetch objects. Browsers double the number of concurrent connections on non-keepalive sites to compensate for this.

However, I'm planning on implementing both features in future versions, because it appears that there are users who mostly need availability above performance, and for them, it's understandable that having both features will not impact their performance, and will reduce the number of components.

Supported platforms

• Linux 2.4 on x86, x86_64, Alpha, SPARC, MIPS, PARISC
• Linux 2.6 on x86, ARM (ixp425), PPC64
• Solaris 8/9 on UltraSPARC 2 and 3
• Solaris 10 on Opteron and UltraSPARC
• FreeBSD 4.10 - 6.2 on x86
• OpenBSD 3.1 to -current on i386, amd64, macppc, alpha, sparc64 and VAX (check the ports)

Highest performance should be achieved with haproxy versions newer than 1.2.5 running on Linux 2.6, or epoll-patched Linux kernel 2.4. It is only because of a very OS-specific optimization : the default polling system for version 1.1 is select(), which is common among most OSes, but can become slow when dealing with thousands of file-descriptors. Versions 1.2 and 1.3 uses poll() by default instead of select(), but on some systems it may even be slower. However, it is recommended on Solaris as its implementation is rather good. Haproxy 1.3 will automatically use epoll on Linux 2.6 and patched Linux 2.4, and kqueue on FreeBSD and OpenBSD. Both mechanisms achieve constant performance at any load thus are preferred over poll().

On very recent Linux 2.6 (>= 2.6.27.19), HAProxy can use the new splice() syscall to forward data between interfaces without any copy. Performance above 10 Gbps may only be achieved that way.

Based on those facts, people looking for a very fast load balancer should consider the following options on x86 or x86_64 hardware, in this order :

1. HAProxy 1.3 on Linux 2.6.27+
2. HAProxy 1.3 on Linux 2.4 + epoll
3. HAProxy 1.3 on Linux 2.6.16 + scheduler starvation fixes
4. HAProxy 1.3 on FreeBSD
5. HAProxy 1.3 on Solaris 10

Current typical 1U servers equipped with a dual-core Opteron or Xeon generally achieve between 15000 and 30000 hits/s and have no trouble saturating 2 Gbps under Linux.

Performance

Well, since a user's testimony is better than a long demonstration, please take a look at Chris Knight's experience with haproxy saturating a gigabit fiber on a video download site. Another big data provider I know constantly pushes between 2 and 3 Gbps of traffic 24 hours a day. Also, my experiments with Myricom's 10-Gig NICs might be of interest.

HAProxy involves several techniques commonly found in Operating Systems architectures to achieve the absolute maximal performance :

• a single-process, event-driven model considerably reduces the cost of context switch and the memory usage. Processing several hundreds of tasks in a millisecond is possible, and the memory usage is in the order of a few kilobytes per session while memory consumed in Apache-like models is more in the order of megabytes per process.
• O(1) event checker on systems that allow it (Linux and FreeBSD) allowing instantaneous detection of any event on any connection among tens of thousands.
• Single-buffering without any data copy between reads and writes whenever possible. This saves a lot of CPU cycles and useful memory bandwidth. Often, the bottleneck will be the I/O busses between the CPU and the network interfaces. At 10 Gbps, the memory bandwidth can become a bottleneck too.
• MRU memory allocator using fixed size memory pools for immediate memory allocation favoring hot cache regions over cold cache ones. This dramatically reduces the time needed to create a new session.
• work factoring, such as multiple accept() at once, and the ability to limit the number of accept() per iteration when running in multi-process mode, so that the load is evenly distributed among processes.
• tree-based storage, making heavy use of the Elastic Binary tree I have been developping for several years. This is used to keep timers ordered, to keep the runqueue ordered, to manage round-robin and least-conn queues, with only an O(log(N)) cost.
• optimized HTTP header analysis : headers are parsed an interpreted on the fly, and the parsing is optimized to avoid an re-reading of any previously read memory area. Checkpointing is used when an end of buffer is reached with an incomplete header, so that the parsing does not start again from the beginning when more data is read. Parsing an average HTTP request typically takes 2 microseconds on a Pentium-M 1.7 GHz.
• careful reduction of the number of expensive system calls. Most of the work is done in user-space by default, such as time reading, buffer aggregation, file-descriptor enabling/disabling.

All these micro-optimizations result in very low CPU usage even on moderate loads. And even at very high loads, when the CPU is saturated, it is quite common to note figures like 5% user and 95% system, which means that the HAProxy process consumes about 20 times less than its system counterpart. This explains why the tuning of the Operating System is very important. I personnally build my own patched Linux 2.4 kernels, and finely tune a lot of network sysctls to get the most out of a reasonable machine.

This also explains why Layer 7 processing has little impact on performance : even if user-space work is doubled, the load distribution will look more like 10% user and 90% system, which means an effective loss of only about 5% of processing power. This is why on high-end systems, HAProxy's Layer 7 performance can easily surpass hardware load balancers' in which complex processing which cannot be performed by ASICs has to be performed by slow CPUs. Here is the result of a quick benchmark performed on haproxy 1.3.9 at EXOSEC on a single core Pentium 4 with PCI-Express interfaces:

• The session rate
  This factor is very important, because it directly determines when the load balancer will not be able to distribute all the requests it receives. It is mostly dependant on the CPU. Sometimes, you will hear about requests/s or hits/s, and they are the same as sessions/s in HTTP/1.0 or HTTP/1.1 with keep-alive disabled. Requests/s with keep-alive enabled does not mean anything, and is generally useless because it is very often that keep-alive has to be disabled to offload the servers under very high loads. This factor is measured with varying object sizes, the fastest results generally coming from empty objects (eg: HTTP 302, 304 or 404 response codes). Session rates above 20000 sessions/s can be achieved on Dual Opteron systems such as HP-DL145 running a carefully patched Linux-2.4 kernel. Even the cheapest Sun's X2100-M2 achieves 25000 sessions/s in dual-core 1.8 GHz configuration.
• The session concurrency
  This factor is tied to the previous one. Generally, the session rate will drop when the number of concurrent sessions increases (except the epoll polling mechanism). The slower the servers, the higher the number of concurrent sessions for a same session rate. If a load balancer receives 10000 sessions per second and the servers respond in 100 ms, then the load balancer will have 1000 concurrent sessions. This number is limited by the amount of memory and the amount of file-descriptors the system can handle. With 8 kB buffers, HAProxy will need about 16 kB per session, which results in around 60000 sessions per GB of RAM. In practise, socket buffers in the system also need some memory and 40000 sessions per GB of RAM is more reasonable. Layer 4 load balancers generally announce millions of simultaneous sessions because they don't process any data so they don't need any buffer. Moreover, they are sometimes designed to be used in Direct Server Return mode, in which the load balancer only sees forward traffic, and which forces it to keep the sessions for a long time after their end to avoid cutting sessions before they are closed.
• The data rate
  This factor generally is at the opposite of the session rate. It is measured in Megabytes/s (MB/s), or sometimes in Megabits/s (Mbps). Highest data rates are achieved with large objects to minimise the overhead caused by session setup and teardown. Large objects generally increase session concurrency, and high session concurrency with high data rate requires large amounts of memory to support large windows. High data rates burn a lot of CPU and bus cycles on software load balancers because the data has to be copied from the input interface to memory and then back to the output device. Hardware load balancers tend to directly switch packets from input port to output port for higher data rate, but cannot process them and sometimes fail to touch a header or a cookie. For reference, the Dual Opteron systems described above can saturate 2 Gigabit Ethernet links on large objects, and I know people who constantly run between 2 and 3 Gbps of real traffic on 10-Gig NICs plugged into quad-core servers.

A load balancer's performance related to these factors is generally announced for the best case (eg: empty objects for session rate, large objects for data rate). This is not because of lack of honnesty from the vendors, but because it is not possible to tell exactly how it will behave in every combination. So when those 3 limits are known, the customer should be aware that he will generally be below all of them. A good rule of thumb on software load balancers is to consider an average practical performance of half of maximal session and data rates for average sized objects.

You might be interested in checking the 10-Gigabit/s page.

Reliability - keeping high-traffic sites online since 2002

Security - Not even one vulnerability in 7 years

HAProxy also provides regex-based header control. Parts of the request, as well as request and response headers can be denied, allowed, removed, rewritten, or added. This is commonly used to block dangerous requests or encodings (eg: the Apache Chunk exploit), and to prevent accidental information leak from the server to the client. Other features such as Cache-control checking ensure that no sensible information gets accidentely cached by an upstream proxy consecutively to a bug in the application server for example.

Download

• Development version :
  • Browse directory for docs, sources and binaries
  • Daily snapshots are built once a day when the GIT repository changes
  • NSLU2 binaries are regularly built by Jeff Buchbinder

• Latest version (1.3) :
  • Release Notes for version 1.3.17
  • haproxy-1.3.17.tar.gz (MD5) : Source code under GPL
  • haproxy-1.3.17-linux-i586.gz : (MD5) Linux/i586 executable linked with Glibc 2.2
  • haproxy-1.3.17-pcre-solaris-sparc.notstripped.gz : (MD5) Solaris8/Sparc executable
  • Browse directory for other files or versions

• Previous branch (1.2) :
  • Release Notes for version 1.2.18
  • haproxy-1.2.18.tar.gz (MD5) : Source code under GPL
  • haproxy-1.2.18-linux-i586.gz : (MD5) Linux/i586 executable linked with Glibc 2.2
  • haproxy-1.2.18-sol8-ultrasparc-static-pcre.gz : (MD5) Solaris8/Sparc executable
  • haproxy-1.2.18-sol10-i686-static-pcre.gz : (MD5) Solaris10/x86 executable
  • Browse directory for other files or versions

• X-Forwarded-For support for Stunnel

  Stunnel currently makes a perfect complement to provide SSL client-side support to HAProxy. However, since Stunnel is a proxy an has no knowledge of HTTP, the client's IP address was lost, which is somewhat annoying. A few patches were available on the Net to add the X-Forwarded-For header, but they introduced an undesirable buffer overflow. So I took my courage and wrote a reliable and secure patch to implement this useful feature. I sent it to Stunnel's authors but got no feedback. So the patch is provided here for Stunnel-4.14, 4.15, 4.20 and 4.22 in the hope it will be useful to some people.

  • stunnel-4.14-xforwarded-for.diff
  • stunnel-4.15-xforwarded-for.diff
  • stunnel-4.20-xforwarded-for.diff
  • stunnel-4.22-xforwarded-for.diff (rediffed by Alexey Pechnikov)
  • Browse directory for other versions

• Various Patches :
  • epoll-lt-2.4.32-0.23.diff : kernel patch to enable epoll on standard Linux 2.4 kernels.
  • linux-2.4.21-40.EL-custom.diff : kernel patch to enable epoll on Red Hat Enterprise Linux 3 U7.
  • tcp_splice-0.1.1-linux-2.4.33.diff : patch to L7SW to provide TCP splicing support to standard Linux 2.4 kernels.
  • 1.3.15-cond-redirect.diff : patch for 1.3.15 to enable conditionnal redirects.
  • stunnel-4.20-listen-queue.diff : patch for stunnel 4.20 to increase listen queue.
  • Browse directory for other patches

• Logo :

  If you are a happy user of haproxy and want to put a reference to it on your site, simply copy the following HTML code where you feel appropriate on your site, it will present the logo above to your visitors :
  <a href="http://haproxy.1wt.eu/"><img src="http://haproxy.1wt.eu/img/pwby.gif" border=0 align=center alt="powered by HAPROXY"></a>

• Browsable directory

Documentation

• Reference Manual for version 1.3 (stable) :
  • configuration.txt : Configuration Manual (English)
  • architecture.txt : Architecture Guide (English)
  • haproxy-en.txt : English version, outdated
  • haproxy-fr.txt : French version, outdated
  • Browsable directory : Various other docs and diagrams
• Reference Manual for version 1.2 (old stable) :
  • haproxy-en.txt : English version
  • haproxy-fr.txt : French version
• Reference Manual for version 1.1 (unmaintained) :
  • haproxy-en.txt : English version
  • haproxy-fr.txt : French version
• architecture.txt : Architecture Guide (English)
• Article on Load Balancing (HTML version) : worth reading for people who don't know what type of load balancer they need (English)
  • PDF version (English)
  • PDF version (French)

Commercial Support (France)

If you think you don't have the time and skills to setup and maintain a free load balancer, or if you're seeking for commercial support to satisfy your customers or your boss, you should contact EXOSEC. Another solution would be to use Exceliance's ALOHA appliances (see below).

Products using HAProxy

• redWall Firewall
  From the site : "redWall is a bootable CD-ROM Firewall. Its goal is to provide a feature rich firewall solution, with the main goal, to provide a webinterface for all the logfiles generated!"
• Exceliance's ALOHA Load Balancer appliance
  Exceliance is a french company who sells a complete haproxy-based solution embedding an optimized and hardened version of Formilux packaged for ease of use via a full-featured Web interface, reduced maintenance, and enhanced availability through the use of VRRP for box fail-over, bonding for link fail-over, configuration synchronization, SSL, transparent mode, etc... (check differences between HAProxy and Aloha). An evaluation version running in VMWare Player is available on the site. Since this is where I work, a lot of features are created there :-)
• Loadbalancer.org
  This company based in the UK has recently added HAProxy to their load-balancing solution in order to provide the basic layer 7 support that some customers were asking for. They're also among the rare commercial product makers who admit to use HAProxy and who have donated to the project.

Contributions

• Application Cookies

  Aleksandar Lazic and Klaus Wagner implemented this feature which was merged in 1.2. It allows the proxy to learn cookies sent by the server to the client, and to find it back in the URL to direct the client to the right server. The learned cookies are automatically purged after some inactive time.

• FreeBSD Port

  Clément Laforet maintains an up to date port of haproxy for FreeBSD. If you want more information about this port, please consult Clément's work here :

  http://www.freebsd.org/cgi/url.cgi?ports/net/haproxy/pkg-descr
  http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/haproxy/
  http://www.freshports.org/net/haproxy

• Debian/Ubuntu Package

  Arnaud Cornet has brought HAProxy to Debian :

  http://packages.debian.org/haproxy

• OpenBSD port

  Jason Dixon has committed a port of haproxy into OpenBSD -current

• Least Connections load balancing algorithm

  This patch for haproxy-1.2.14 was submitted by Oleksandr Krailo. It implements a basic least connection algorithm. I've not merged this version into 1.3 because of scalability concerns, but I'm leaving it here for people who are tempted to include it into version 1.2, and the patch is really clean.

  haproxy-1.2.14-leastconn.diff

• Soft Server-Stop

  Aleksandar Lazic sent me this patch against 1.1.28 which in fact does two things. The first interesting part allows one to write a file enumerating servers which will have to be stopped, and then sending a signal to the running proxy to tell it to re-read the file and stop using these servers. This will not be merged into mainline because it has indirect implications on security since the running process will have to access a file on the file-system, while current version can run in a chrooted, empty, read-only directory. What is really needed is a way to send commands to the running process. However, I understand that some people might need this feature, so it is provided here. The second part of the patch has been merged. It allowed both an active and a backup server to share a same cookie. This may sound obvious but it was not possible earlier.

  haproxy_comafile+multi-cookie.diff

  Usage: Aleks says that you just have to write the server names that you want to stop in the file, then kill -USR2 the running process. I have not tested it though.

• Server Weight

  Sébastien Brize sent me this patch against 1.1.27 which adds the 'weight' option to a server to provide smoother balancing between fast and slow servers. It is available here because there may be other people looking for this feature in version 1.1.
  
  I did not include this change because it has a side effect that with high or unequal weights, some servers might receive lots of consecutive requests. A different concept to provide a smooth and fair balancing has been implemented in 1.2.12, which also supports weighted hash load balancing.

  patch-haproxy-1.1.27-weight

  Usage: specify "weight X" on a server line.
  Note: configurations written with this patch applied will normally still work with future 1.2 versions.

• IPv6 support for 1.1.27

  I implemented IPv6 support on client side for 1.1.27, and merged it into haproxy-1.2. Anyway, the patch is still provided here for people who want to experiment with IPv6 on HAProxy-1.1.

  haproxy-1.1.27-ipv6.diff

• Other patches

  Please browse the directory for other useful contributions.

Other Solutions

• Linux Virtual Servers (LVS)
  Very fast layer 3/4 load balancing merged in Linux 2.4 and 2.6 kernels. Should be coupled with Keepalived to monitor servers. This generally is the solution embedded by default in most IP-based load balancers.
• Pure Load Balancer (PLB)
  The author adopted the same event-driven model as in HAProxy (but relying on libevent). Interestingly, he has the same conclusions about other models's limitations. However, his goal is just to achieve high performance and availability, without any particular HTTP processing nor persistence.
• Pound
  Pound can be seen as a complement to HAProxy. It supports SSL, and can direct traffic according to the requested URL. Its code is very small and will stay small for easy auditing. Its configuration file is very small too. However, it does not support persistence, and the performance associated to its multi-threaded model limits its usage to medium sites only.
• Pen
  Pen is a very simple load balancer for TCP protocols. It supports source IP-based persistence for up to 2048 clients. Supports IP-based ACLs. Uses select() and supports higher loads than Pound but will not scale very well to thousands of simultaneous connections.

Contacts

• mailing-list :
  Read the archives on Formilux site
  Subscribe to the list :
• Main site : http://1wt.eu/
• This site in IPv6 : http://haproxy.ipv6.1wt.eu/ (should be OK if you see a green square here ⇒ )
• e-mail :

Some people regularly ask if it is possible to send donations, so I have set up a Paypal account for this. Click here if you want to donate.

An IRC channel for haproxy has been opened on FreeNode (but don't seek me there, I'm not) :

irc://irc.gnu.org/%23haproxy

External links

• Setting up a high availability load blancer with haproxy and keepalived on debian lenny
• Configure HAProxy with TPROXY kernel for full transparent proxy
• Installing HAProxy load-balancing for HTTP and HTTPS
• HAProxy, X-Forwarded-For, GeoIP, KeepAlive
• Load Balancing in Amazon EC2 with HAProxy
• CouchDB Load Balancing and Replication using HAProxy
• Zero-Downtime restarts with HAProxy
• Free your port 80 with HAProxy
• Another comparison of HAProxy and Nginx
• Scaling on EC2
• HAProxy on Opensolaris 2008.05
• Load-Balancing and QoS with HAProxy
• Reviewing Application Health with HAProxy Stats
• Installation de HAProxy + Heartbeat sous Debian (FR)