HAProxy

The Reliable, High Performance TCP/HTTP Load Balancer

Quick links

	Web 1wt.eu

Quick News

A few bugs were fixed since 1.4.18, and they impacted users so I wanted to release something now eventhough none of them is critical. First, Sagi Bashari fixed the usage of alternative header name for the "forwardfor" option. An incompatibility between server tracking and slowstart, was diagnosed by Ludovic Levesque : the weight would remain at the lowest level forever. Daniel Rankov reported that option nolinger did not work in backends. It looks like it has been the case for a very long time now. An issue in the string indexing in ebtrees was diagnosed by Julien Thomas. It is used in ACLs could theorically affect the ACL code though it has no visible effect since all patterns in the same ACL are interchangeable. Timothy Garnett reported an issue where Ruby clients were experiencing an extra delay in response time. After analyzing some network traces, it appeared that Ruby likes to send POST requests in multiple incomplete packets, waiting for the first one to be ACKed before pushing the rest, which is incompatible with the delayed ACK. Since we get the incomplete request, we can notice that it's missing data and re-enable quick ACKs to make the client send the rest ASAP. Obvously the client should be fixed as its behaviour makes it very sensible to network latency. Brian Lagoni reported that TProxy broke after Linux 2.6.34 kernel, because the address family was previously assumed to be AF_INET and was not set in HAProxy. Last bug, I was fed up with HAProxy blocking invalid server responses which were sent without headers. I finally understood that it was because some requests were sent with a "\0" in the URI which HAProxy did not block, and Apache considered the request line truncated and ignored the HTTP version, resulting in HTTP/0.9. So the request parser was modified to reject control characters in the URI (the standard forbids other characters but we can't change too much in a stable version without risking breaking some setups). One minor feature was merged. Mark Lamourine worked on a solution to send a server's name in a header when connections are established to a server. I know this can be useful in some silo-like setups and the code does not present any risk of regression so I accepted to include it in 1.4. So 1.4.19 was released with all these changes. If you have no problem with current version, there is no need to upgrade.

September 16th, 2011 : Stable 1.4.18

The fix for the space parsing in the headers that I made of 1.4.17 was not complete, because it results in negative header lengths being returned for headers that are exclusively composed of spaces. I have checked the whole code to see if this can have any nasty effect, and I couldn't find one, since everytime, we check the length before the contents (we're saved by an optimization). Still, I don't like having dangerous code lie around, especially in stable versions. I know for instance that some people apply custom patches on top of it and may get trapped. So i have issued 1.4.18 with that fix. I also included the recent patch from Finn Arne Gangstad to split domain names on ':' too, as I agree that whenever a port is specified, the host name cannot easily be checked. And I added a match for header length so that it's now a lot easier to check for an empty header. The rest are just usual doc and halog updates. I don't think there is any specific reason to rush on this new version, but if you're in the process of upgrading an older one, please avoid 1.4.17 and use 1.4.18 instead.

September 10th, 2011 : Development 1.5-dev7

Five months have elapsed since 1.5-dev6. A massive amount of changes was merged since then. Most of them were cleanups and optimizations. A number of changes were dedicated to making listeners more autonomous. The immediate effect is a more robust handling of resource saturation, and the second effect is the removal of the 10-years old maintain_proxies() function which was harming performance and hard to get over. Halog was improved too (faster with more filters). A significant number of external contributions were merged, among them the stats socket updates to clear session-table keys by values. There are too many changes to list, but nothing too dangerous, so I'd say it's the 1.5-dev version I trust the most today. Please give it a test.

September 5th, 2011 : Stable 1.4.17

Last week an issue was discovered with an application emitting spaces after the content-length value, which caused haproxy to report an error when parsing it. After some checks, it appeared that haproxy ought to ignore these spaces, so this was addressed. It was an opportunity to improve invalid request and responses captures, so that any message rejected for its malformation can be captured. A new minor feature making the X-Forwarded-For header addition conditional was added because users had to resort to complex tricks to do that. Last, halog was updated to latest version. Due to the issue with the header above, I released 1.4.17. Quite frankly most users don't need to upgrade. However it's better to use this one for new deployments.

August 6th, 2011 : Stable 1.3.26 and status updates

Previous 1.3 version was released 14 months ago, the same day as 1.4.8. Since then, a number of fixes went into 1.4 and a part of them were queued for 1.3. These fixes are not *that much* important but are still worth a release. Thus, both 1.3.26 and 1.3.15.13 were released and are available as source and precompiled binaries for Linux/x86 and Solaris/sparc.

I realized that I don't use 1.3 anymore myself, and for this reason I'm afraid of the risk of introducing regressions with future backports. So I decided that it was time to turn 1.3 into a "critical fixes only" status after 2.5 years of stable releases and 5 years of existence, meaning that minor fixes will probably never get there anymore, and that future releases, if any, will be focused on important bugs. That does not mean it's not supported anymore, but that fixes will come at a very slow pace and that new deployments are encouraged to use 1.4 if they expect a responsive support.

I'm also switching the 1.3.14 and 1.2 branches to the "unmaintained" status since nobody appears to be using them anymore (last fixes were more than 2 and 3 years ago respectively).

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 :

• version 1.4 - more flexibility
  This version has brought its share of new features over 1.2, most of which were long awaited : client-side keep-alive to reduce the time to load heavy pages for clients over the net, TCP speedups to help the TCP stack save a few packets per connection, response buffering for an even lower number of concurrent connections on the servers, RDP protocol support with server stickiness and user filtering, source-based stickiness to attach a source address to a server, a much better stats interface reporting tons of useful information, more verbose health checks reporting precise statuses and responses in stats and logs, traffic-based health to fast-fail a server above a certain error threshold, support for HTTP authentication for any request including stats, with support for password encryption, server management from the CLI to enable/disable and change a server's weight without restarting haproxy, ACL-based persistence to maintain or disable persistence based on ACLs, regardless of the server's state, log analyzer to generate fast reports from logs parsed at 1 Gbyte/s,
• 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 has been in production use since 2006 and provided an improved performance level on top of 1.1. It is not maintained anymore, as most of its users have switched to 1.3 a long time ago. Version 1.1, which has been maintaining critical sites online since 2002, is not maintained anymore either. Users should upgrade to 1.4.

For a long time, HAProxy was used only by a few hundreds of people around the world running very big sites serving several millions hits and between several tens of gigabytes to several terabytes per day to hundreds of thousands of clients, who needed 24x7 availability and who had internal skills to risk to maintain a free software solution. Over the years, things have changed a bit, HAProxy has become the de-facto standard load balancer, and it's often installed by default in cloud environments. Since it does not advertise itself, we only know it's used when the admins report it :-)

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. With version 1.4, keep-alive with the client was introduced. It resulted in lower access times to load pages composed of many objects, without the cost of maintaining an idle connection to the server. It is a good trade-off. 1.5 will bring keep-alive to the server, but it will probably make sense only with static servers.

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, x86_64, ARM (ixp425), PPC64
• Solaris 8/9 on UltraSPARC 2 and 3
• Solaris 10 on Opteron and UltraSPARC
• FreeBSD 4.10 - 8 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.4 on Linux 2.6.27+
2. HAProxy 1.4 on Linux 2.4 + epoll patch
3. HAProxy 1.4 on Linux 2.6.16 + scheduler starvation fixes
4. HAProxy 1.4 on FreeBSD
5. HAProxy 1.4 on Solaris 10

Current typical 1U servers equipped with a dual-core Opteron or Xeon generally achieve between 15000 and 40000 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 3 and 4 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 20000 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 3 and 4 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 10 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 :
  • Documentation
  • Browse directory for docs, sources and binaries
  • Daily snapshots are built once a day when the GIT repository changes

• Latest version (1.4) :
  • Documentation
  • Release Notes for version 1.4.19
  • haproxy-1.4.19.tar.gz (MD5) : Source code under GPL
  • haproxy-1.4.19-linux-i586.gz : (MD5) Linux/i586 executable linked with Glibc 2.2
  • haproxy-1.4.19-pcre-solaris-sparc.notstripped.gz : (MD5) Solaris8/Sparc executable
  • NSLU2 binaries are regularly built by Jeff Buchbinder
  • Browse directory for other files or versions

• Latest version (1.3) :
  • Documentation
  • Release Notes for version 1.3.26
  • haproxy-1.3.26.tar.gz (MD5) : Source code under GPL
  • haproxy-1.3.26-linux-i586.gz : (MD5) Linux/i586 executable linked with Glibc 2.2
  • haproxy-1.3.26-pcre-solaris-sparc.notstripped.gz : (MD5) Solaris8/Sparc executable
  • NSLU2 binaries are regularly built by Jeff Buchbinder
  • Browse directory for other files or versions

• Previous branch (1.2) :
  • Documentation
  • 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
  • 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 various versions from Stunnel-4.14 and above in the hope it will be useful to some people. At least it seems to be the case, considering the number of people who send updates :-) Note that this patch does not work with keep-alive, see send-proxy below for that.

  Get the patches from Exceliance's public patch repository

• Send-proxy support for Stunnel

  This patch contributed by Exceliance adds to stunnel the ability to inform haproxy about the incoming connection (protocol, source, destination, ...). It's more flexible than the X-Forwarded-For patch above, but requires haproxy 1.5-dev3 minimum with support for the accept-proxy bind option. This feature has been merged into stunnel 4.45, so the patch is not needed anymore starting from this version.

  Get the patches from Exceliance's public patch repository

• Unix socket support for Stunnel

  This patch contributed by Exceliance adds to stunnel the ability to connect to haproxy over a UNIX stream socket instead of using TCP. Sometimes this can be more convenient and/or more secure. It requires haproxy 1.5-dev3 minimum.

  Get the patches from Exceliance's public patch repository

• Other Stunnel patches

  There are other patches contributed to Stunnel by Exceliance, such as multi-process SSL session synchronization, transparent binding and performance improvements. Please check them below.

  Get the patches from Exceliance's public patch repository

• Various Patches :
  • http://www.exceliance.fr/download/free/patches/linux/epoll-2.4/ : kernel patches to enable epoll on standard Linux 2.4 kernels and on Red Hat Enterprise Linux 3.
  • Exceliance's public patch repository for other patches (stud, stunnel, linux, keepalived, ...)
  • Browse directory for other (outdated) 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.4 (stable) :
  • configuration.txt : Configuration Manual (English)
  • Browsable directory : Various other docs and diagrams
• Reference Manual for version 1.3 (stable) :
  • configuration.txt : Configuration Manual (English)
  • architecture.txt : Architecture Guide (English)
  • haproxy-en.txt : old English version, outdated
  • haproxy-fr.txt : old 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)

An automated format converter is being developed by Pavel Lang. At the time of writing these lines, it is able to produce a PDF from the documentation, and some heavy work is ongoing to support other output formats. Please consult the project's page for more information. Here's an example of what it is able to do on version 1.5 configuration manual.

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 by mail here or fill a form here. Another solution would be to use Exceliance's ALOHA appliances or the HAPEE distribution (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 :-)
• Exceliance's HAPEE distribution
  HAPEE is 100%-software alternative to the ALOHA and standard HAProxy, which runs on standard distributions. It offers pre-patched add-ons (eg: stunnel, ...), system settings, commented config files and command line completion to ease the setup of a complete HAProxy-based load balancer, including VRRP and logging. It also comes with support contracts and assistance tickets.
• 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.
• Snapt HAPROXY
  Snapt develops graphical user interfaces for a few products among which HAProxy. They managed to build a dynamic configuration interface which allows the user to play with a very wide range of settings, including ACLs, and to propose contextual choices when additional options are required (eg: backend lists for some ACLs). They have an online demo which is worth testing.

Add-on features and contributions

This table enumerates all known significant contributions, as well as proposed fundings and features yet to be developped but waiting for spare time.

Some older code contributions which possibly do not appear in the table above are still listed here.

• 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.

• 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.
• Nginx ("engine X")
  Nginx is an excellent piece of software. Initially it's a very fast and reliable web server, but it has grown into a full-featured proxy which can also offer load-balancing capabilities. Nginx's load balancing features are less advanced than haproxy's but it can do a lot more things (eg: compression, caching), which explains why they are very commonly found together. I strongly recommend it to whoever needs a fast, reliable and flexible web server !
• 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 :
  Unsubscribe from 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