有人在邮件列表问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 hundredsof bytes per session, as opposed to a few tens of kB of buffers forproxies. However, L4 LBs have to deal with TIME_WAIT, which proxiesdon't since it's done in the system, so in practice, the ratio is notreally tens-of-thousands to millions but rather tens-of-thousands tohundreds-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 kerneltuning. With todays 64-bit systems and cheap RAM, there's plenty ofmargin. We had one user who reported 1 million established connectionsin a bench, and several ones reported more than 300k in production. InLinux, by default, processes are limited to 1 million FDs so you needto patch the kernel or to run in multi-process mode for this. I assumeit's not that crazy to run several processes when you have to deal with1 million concurrent connections :-)
if you don't need any form of session persistence or content switching,
LVS might be more suited for this usage.
阅读(1504) | 评论(0) | 转发(0) |