Scaling Past the Bottleneck: A Sysadmin's Guide to HAProxy 1.4

It starts with a creeping load average. Then, the Apache MaxClients limit hits. Suddenly, your monolithic server falls over right when your marketing campaign goes live. I’ve seen it happen too many times: a perfectly good LAMP stack brought to its knees because someone thought a single quad-core box could handle the entire population of Oslo hitting 'Refresh' at once.

In 2010, throwing more RAM at the problem isn't always the answer. The answer is horizontal scalability. While hardware load balancers like F5 Big-IP are standard for banks with endless budgets, the pragmatic choice for the rest of us is HAProxy. It is robust, free, and when configured correctly on a solid VPS, it can handle tens of thousands of concurrent connections without breaking a sweat.

The Architecture: Why Decoupling Matters

Many developers today are moving toward Nginx as a web server, but for pure load balancing, HAProxy remains the heavyweight champion. Version 1.4, released earlier this year, has solidified its reputation for stability. The goal is simple: sit HAProxy in front of your web nodes and let it distribute traffic based on health and load.

Here is the reference architecture we use for high-availability setups on CoolVDS:

• Load Balancer: 1x CoolVDS Instance (CentOS 5.5, HAProxy 1.4)
• Web Tier: 2x Web Nodes (Apache 2.2, PHP 5.2)
• Database: 1x MySQL 5.1 Server (Master)

Pro Tip: Don't run your load balancer on the same physical disk array as your database if you can avoid it. Database I/O wait can starve the balancer's logging processes. This is why we isolate resources strictly at the hypervisor level.

Configuration: The Round Robin Approach

Installation on CentOS 5 is straightforward via the EPEL repository, or compiling from source if you want the absolute latest patch. Once installed, the magic happens in /etc/haproxy/haproxy.cfg.

A basic configuration for a sticky-session PHP application looks like this:

global
    log 127.0.0.1 local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode http
    option httplog
    option dontlognull
    retries 3
    option redispatch
    maxconn 2000
    contimeout 5000
    clitimeout 50000
    srvtimeout 50000

listen webfarm 0.0.0.0:80
    mode http
    stats enable
    stats uri /haproxy?stats
    balance roundrobin
    cookie PHPSESSID prefix
    option httpclose
    option forwardfor
    server web01 10.0.0.1:80 cookie A check
    server web02 10.0.0.2:80 cookie B check

Let's dissect the critical flags:

• balance roundrobin: Distributes requests sequentially. Simple and effective for similar-spec servers.
• cookie PHPSESSID prefix: This is vital. It modifies the session cookie to ensure a user stays connected to the same backend server (web01 or web02). Without this, your users will get logged out every time the balancer switches nodes.
• option forwardfor: Since the backend sees the IP of the load balancer, this header passes the actual client IP to Apache.

Latency and Sovereignty: The Norwegian Context

Technical configuration is only half the battle. Infrastructure location is the other. If your target audience is in Norway, hosting your load balancer in Germany or the US adds unavoidable latency. We are talking about the difference between 150ms and 10ms ping times.

Furthermore, with the Personal Data Act (Personopplysningsloven) strictly enforced by Datatilsynet, keeping data within Norwegian borders is not just a performance tweak—it is often a compliance necessity. Using a local provider ensures that your customer data isn't traversing trans-Atlantic cables where legal jurisdiction gets murky.

The Storage Bottleneck

Even the best load balancing config cannot save you if your disk I/O is thrashing. In 2010, 15k RPM SAS drives in RAID-10 are the standard for performance, but we are seeing the emergence of Enterprise SSDs changing the game. For database-heavy workloads behind your load balancer, ensure your provider offers high-performance storage. Slow disk reads on the database layer will cause connection pile-ups at the HAProxy layer, resulting in 503 errors regardless of your balancing algorithm.

Why CoolVDS?

We don't oversell our nodes. When you deploy a load balancer, you need consistent CPU scheduling to handle the context switching of thousands of packets. We use Xen virtualization to ensure hard isolation. While others cram users onto OpenVZ containers where "noisy neighbors" can steal your CPU cycles, CoolVDS guarantees the resources you pay for.

Don't wait for your site to crash during the next traffic spike. Spin up a test environment, install HAProxy, and see the stability for yourself.

Ready to stabilize your stack? Deploy a high-availability VPS Norway instance on CoolVDS today.