HAProxy Reviews

Load balancing and SSL termination.

HAProxy enabled better performance at lower costs. That enabled us to provide more stability to our clients.

Performance.

A better GUI would be nice.

No issues with stability.

No issues with scalability.

Very professional, helpful.

We used F5 BIG-IP in the past and switchED due to performance issues and costs.

It is mostly straightforward and HAProxy was very helpful, guiding us during the deployment.

I think that the pricing is very fair, I would definitely recommend buying the Enterprise license.

Citrix Netscaler and Kemp LoadMaster.

HAProxy is a very powerful solution with great performance, but it needs to be evaluated carefully according to the specific environment and requirements.

I'm using HAProxy in two use cases. 

The first is as an internal load balancer for OpenStack services, in private cloud solutions. So HAProxy is used in front of Galera (MySQL cluster), Nova API, and also in front of exposed docker services. 

The second use case is as a load balancer for a Web hosting solution. HAProxy is load balancing external traffic.

Configuration of HAProxy includes brute force sandboxing (including stick tables and hardcoded ACL for defined paths), splitting traffic by dynamic and static content to redirect it to the proper back-end, SSL, and HTTP headers management.

I can simplify configurations of many internal services (e.g. Web server configs) by moving some elements (like SSL) to HAProxy. I can also disable additional applications, like Varnish, by moving traffic shaping configurations to HAProxy.

Advanced traffic rules, including stick tables and ACLs, which allow me to shape traffic while it's load balanced.

Performance configuration options with threads, processes, and core stickiness are also very valuable.

In my opinion, there are three main areas to improve:

1. Make remote management more modern by adding API.
2. Propose a general HA solution for HAProxy (no I'm using keepalived for this).
3. Thread option should be a bit more stable.

No issues with stability.

No issues with scalability, but multiprocess config for HAProxy is more efficient than multi-thread.

I used NGINX in my Web environment. HAProxy has more traffic shaping options and it's a dedicated VNF load-balancer.

Initial setup was straightforward. The documentation is pretty thorough and up to date, and it is also easy to search.

During the implementation, you have to plan ACLs and back-ends first. That allows you to prepare a cleaner config.

I rate HAProxy a 10 out of 10. It is fast, flexible, and rock solid.

With an OpenShift environment, HAProxy gives us an easy way to handle a lot of containers.

The ability to handle a sequence of front- and back-ends gives the user the opportunity to send traffic through different services.

HAProxy needs to improve its ability to handle a lot of connections, to be more like NGINX.

No issues with stability.

I haven't had any issues with scalability but, as I mentioned above, some reviewers have said that NGINX is able to handle more connections than HAProxy.

It was straightforward. I created an Ansible playbook to install HAProxy. It is simple to install and the configuration files are easy to understand.

I have always used an open-source version.

Before using it, you need to understand your environment's sizing and check if HAProxy is able to handle the quantity of connections.

In my previous company, we had a lot of connections with carriers and we had this communication centralized with HAProxy. We had a high-availavility environment with HAProxy, and Keepalived too for database connections.

We were able to use HAProxy for round robin with our databases, or for a centralized TCP connection in one host.

Round robin and monitoring.

From my point of view, the configuration should be more friendly, perhaps with a Web interface. For example, I work with the ClusterControl product for Severalnines, and we have a Web interface to deploy the HAProxy load-balancer.

We are using HAProxy for our internal load balancers between the front-end and back-end services. HAProxies are configured either manually (LVS redundancy included) or automatically (ambassador pattern by using a Consul & Consul-Template).

It reduced the load on our main load balancers.

• Flexible health-checking
• Good config format to auto-configure

We need to handle new connections by dropping, or queuing them while the HAProxy restarts, and because HAProxy does not handle split config files.

No stability issues.

No scalability issues.

We did not need technical support because the documentation is good.

The initial setup is pretty straightforward.

We use NGINX as well. However, because the health checks are a paid feature, I like to avoid it whenever possible.

We pretty much know all the software out there and its capabilities, so we did not evaluate anything else.

Use a split front-end and back-end instead of using the "listen" directive. Therefore, you are clear what you are setting up. 

Be aware of connections dropping during restarts, etc.

We have the following use-cases for HAProxy:

1. To load-balance dozens of Apache 2.4 Servers mod_proxy. (Internal load-balance Tomcat, Jetty, JBoss app containers, using TCP load-balancing).
2. To load-balance hundreds of MySQL and PostgreSQL databases using TCP load-balancing. We manage inventory of these through Ansible automation.
3. To provide a layer of security (username/passwd) authentication for legacy back-end Web apps that may not have username/passwd implemented yet. Some financial Web apps were created over 15 years ago and focused on reports, files, logs, and market share stats and were written in Perl. We also had a very old Kibana interface to visualize those logs. Such Web apps required HAProxy to tunnel the requests with un/pw authentication.
4. To redirect traffic internally based on /URL to the relevant services (DNS nameserver) and as a gateway to tunnel traffic to customers who explicitly require reverse-IP authentication. The DNS nameserver was a trendsetter that we learned quickly and now cannot live without.

As our traffic began increasing nine years ago, we desperately needed to load-balance TCP requests (for DBs). We originally used round robin on an array[] which stored the IPs of half a dozen DBs. But with HAProxy, we didn't need to maintain such complexity. We later exploited many more features.

The most important features would be the load-balancing of HTTP and TCP requests, according to multiple LB algorithms (busyness, weighted-busyness, round robin, traffic, etc). 

Another important feature that we cannot live without is the username/passwd authentication for legacy systems that had none.

The web stats UI, which provides the status of the health and numbers, could greatly benefit from having a RESTful interface to control the load-balanced nodes. Although there is a hack around the UI (by issuing a POST request to HAProxy with parameters), a RESTful interface would greatly improve the automation process (through Chef and Ansible).

I have deployed over 50 instances of HAProxy over the past 15 years and never encountered any stability issues. Most HAProxy instances have continuously run for over two years until the server required a kernel upgrade.

I have used it for over 10 years. I started using it as a Web application (Tomcat, Apache, JBoss) load-balancer when it had a few stable releases. When I first start using it, HAProxy was primarily used to load-balance HTTP requests. Since we are a B2B company that deals primarily with hotel inventory, IP authentication was a must. Therefore, our customers had single end-points to send and receive RESTful requests. To make this viable, we had to use a central server as a proxy to tunnel out the requests. We will continue to use HAProxy as our entry-point and exit-point of the system.

Primary use case of this solution is during PoC, demos, and in development environments. I have found HAProxy very helpful in replicating production environment architecture in a development and testing environment.

It has been a great help for all the use cases noted above, and economical.

Honestly, I have only evaluated the load-balancing feature because that is what I needed in my environment. As you can understand, for development and end-to-end testing, procuring a hardware load-balancer is a pretty expensive a deal.

I would like to evaluate load-balancing algorithms other than round robin and SSL offloading.

Also, it would be helpful if I could logically divide the HAProxy load-balancing into multiple entities so that I would install one HA Proxy LB application which could be used for different Web servers for different applications. I am not sure if these features are available.

I am using HAProxy on a live production Web Server (Apache load balancing). It's a very good open-source solution.

Four to five years back, we were struggling with Web load-balancing; we were facing issues with a single Apache. We got the best, and open-source, solution.

Load balancing, mainly. We are using two Apaches with HAProxy load-balancing.

Some people use HAProxy to load balance MySQL databases as well.

They should introduce one feature that I know many people, including me, are waiting for: HAProxy should have provide hot-swipe for back-end servers, no downtime while shifting back-end servers.

They also need a more detailed GUI for monitoring and configuration.

I have been using this solution for the last four to five years with no downtime.

No issues with scalability.

Easy to set up.

If you don't have expertise then go with the licensed version. Otherwise, open-source is the best solution.

I will always give HAProxy a 10 out of 10. We never have any downtime with it. The HAProxy team regularly updates the product. I would definitely recommend HAProxy. You must go with this product.