Chinaunix首页 | 论坛 | 博客
  • 博客访问: 969854
  • 博文数量: 99
  • 博客积分: 3306
  • 博客等级: 中校
  • 技术积分: 1238
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-21 10:14
文章分类

全部博文(99)

文章存档

2012年(37)

2011年(56)

2010年(6)

分类: LINUX

2012-04-21 16:45:37

有人在邮件列表问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.
阅读(1504) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~