Surviving the Slashdot Effect: High-Performance Load Balancing with HAProxy
It’s 3:00 AM. Your pager goes off. Nagios is screaming that HTTP response time is over 10 seconds.
You check the logs. It’s not a DDoS; you just got linked on Digg or Slashdot. Your single Apache server has hit MaxClients, and the swap file is thrashing your hard drives to death. If you don't fix this in ten minutes, you lose the traffic, the revenue, and your reputation.
Most hosting providers will tell you to upgrade to a dedicated server. They are wrong. You don't need more iron; you need smarter architecture. You need HAProxy.
Why Hardware Load Balancers are Obsolete
In the old days, if you wanted high availability, you bought a Cisco LocalDirector or an F5 Big-IP. They cost as much as a new car. Today, we have open source.
HAProxy (High Availability Proxy) 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 very high traffic web sites. It powers the biggest sites on the web, and it runs beautifully on a standard Linux kernel.
The Architecture: Decoupling Complexity
Instead of one giant server melting down, we use a VDS (Virtual Dedicated Server) as a traffic cop. This load balancer accepts connections and distributes them to backend web nodes.
Here is the setup we use for high-traffic clients on CoolVDS:
- 1x Load Balancer: HAProxy on CentOS 5 (Minimal install).
- 2x Web Nodes: Apache 2.2 serving PHP/MySQL.
- Interconnect: Private Gigabit LAN (low latency).
Configuration: The "Secret Sauce"
Installing HAProxy on CentOS 5 is straightforward via the EPEL repository, but the default config is garbage for high loads. You need to tune it manually.
Here is a battle-tested configuration for /etc/haproxy/haproxy.cfg:
global
log 127.0.0.1 local0
maxconn 4096
user haproxy
group haproxy
daemon
# Spread checks to avoid spikes
spread-checks 5
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 auth admin:password
balance roundrobin
cookie JSESSIONID prefix
option httpclose
option forwardfor
server web01 192.168.1.10:80 cookie A check
server web02 192.168.1.11:80 cookie B check
Breaking Down the Config
The balance roundrobin directive ensures traffic is shared equally. Crucially, the cookie directive creates "sticky sessions." If a user logs into your Magento store on web01, HAProxy ensures they stay on web01 so their shopping cart doesn't vanish.
Pro Tip: Don't forget to raise your file descriptors. HAProxy needs a file descriptor for every connection. Addulimit -n 65535to your startup script or edit/etc/security/limits.conf. If you hit the limit, your site drops packets silently.
Kernel Tuning for the Norwegian Market
Latency kills conversion. If your target audience is in Oslo, Bergen, or Trondheim, network physics matter. Hosting in the US adds 120ms of latency before the first byte is even sent.
CoolVDS servers are located in Oslo with direct peering to the NIX (Norwegian Internet Exchange). But hardware isn't enough. You must tune the TCP stack in /etc/sysctl.conf to handle the bursty traffic common in Northern Europe:
# Allow reusing sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
# Increase the range of ephemeral ports
net.ipv4.ip_local_port_range = 1024 65000
Apply these with sysctl -p. This prevents your load balancer from running out of sockets during high-traffic events.
The Privacy Advantage
We operate under the Norwegian Personopplysningsloven (Personal Data Act) and the Data Protection Directive. By keeping your load balancer and backend databases within Norwegian borders, you simplify compliance with Datatilsynet regulations. Hosting client data outside the EEA can become a legal nightmare quickly.
Why CoolVDS?
You might ask, "Can't I run this on a shared host?" No. Shared hosts don't give you root access to install HAProxy, and they certainly don't let you tune kernel parameters.
You need a Virtual Dedicated Server. However, many VPS providers use OpenVZ, which shares the kernel among all users. This means you cannot modify net.ipv4 settings or load specific modules. CoolVDS uses Xen virtualization. You get your own kernel, your own swap, and guaranteed RAID-10 disk I/O.
When the traffic hits, you don't want "noisy neighbors" stealing your CPU cycles. You want dedicated resources.
Ready to scale? Don't wait for the next crash. Spin up a Xen-based VDS in Oslo today and configure your load balancer before the rush hits.