有人在邮件列表问haproxy的作者为何haproxy无论是tcp模式还是http模式，能支撑的并发量都不是太大。
Willy回答了这个问题。
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.