Au cas où (monitoring) :
Well, this sounds more like a sysadmin training than an haproxy-specific question, but a few things you should have a look at : - is your system swapping ? (it must never) - do you see in your system logs "conntrack table full" ? If so you're hitting some misconfigured conntrack limits - do you see in your system logs "TCP: sending SYN cookies" ? If so you're likely running haproxy with too low a maxconn setting, resulting in connections not being accepted - do you see in your haproxy logs flags "sC" or "SC" while you know your servers are working fine ? If so that could indicate a failure to allocate a source port or a file descriptor for an outgoing connection - do you see your CPU steadily running above, say, 50% ? If so you cannot exclude frequent 100% peaks possibly causing some sub-second delays not reported by the system tools. - and if you're running in a VM, you can redo all this above inside the hypervisor, and in the guest you should also look at the "st" field in vmstat to make sure your CPU is not stolen by other VMs (or goodbye low latency), and you can also run "ping" to your VM from an external host on the same LAN and make sure the latency never jumps above 1 millisecond on a mostly idle network or 2-3 ms on a loaded network or it can indicate that you're have performance issues caused by noisy neighbors on your machine. - connection setup timers exhibiting multiple of 3s in haproxy logs usually indicate packet drops between haproxy and the servers - client timeout errors during request like "cR" often indicate drops or MTU issues between the client and haproxy (sometimes caused by bogus virtualized network drivers). Hoping this helps, Willy