Exactly. The difference is between LBs that process a stream and which are proxy-based, and the ones which process packets and are 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 have to deal with TIME_WAIT, which proxies don‘t since it‘s done in the system, so in practice, the ratio is not really tens-of-thousands to millions but rather tens-of-thousands to hundreds-of-thousands when the connection rate are high.
> and why in HAProxy > you can have "only" thousends of connections while 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 than 300k in production. In Linux, by default, processes are 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 that crazy to run several processes when you have to deal with 1 million concurrent connections :-)
if you don‘t need any form of session persistence or content switching, LVS might be more suited for this usage.
