Someone in the mailing list asked Haproxy why the haproxy, whether TCP or HTTP, is not too large to support the amount of concurrency.
Willy answered the question.Exactly. The difference is between LBs Process a stream and which
is proxy-based, and the ones which process packets and is basically
Routers . In order to parse and modify a stream, you need some memory,
While you don ' t need this to route packets (beyond the routing queue).
L4 load balancers often store a session table which is a few hundreds
of bytes per session, as opposed to a few tens of kB of buffers for
Proxies. However, L4 LBs has to deal with time_wait, which proxies
Don ' t since it's done on the system, so in practice, the ratio are not
Really tens-of-thousands to millions and rather tens-of-thousands to
Hundreds-of-thousands when the connection rate is high.
> and why in HAProxy
> You can has "only" thousends of connections and LVS like LBs can
> Annouce millions ...
> So in Haproxy, whatever the mode, TCP or HTTP, you'll always have
> Thousends of Connexions.
In fact it depends a lot on the configured memory and on the kernel
Tuning. With todays 64-bit systems and cheap RAM, there ' s plenty of
Margin. We had one user who reported 1 million established connections
In a bench, and several ones reported more than300k in production.Inch
Linux, by default, processes is limited to 1 million FDs so you need
To patch the kernel or to run in multi-process mode for this. I assume
It's not this crazy to run several processes if you had to deal with
1 million concurrent connections:-)
If you don ' t need any form of session persistence or content switching,
LVS might is more suited for this usage.
The difference between LVS and other load balancing software
