lvs 工作在第四层 所以受到的主要限制 是CPU、网卡瓶颈限制 服务器一般都是千兆 对于操作系统来说是工作在内核空间
nginx 工作在第七层 受到的限制 CPU、网卡、内存都会有，而且受操作系统影响，每处理一个请求都要消耗一定的内存， 单个nginx进程处理能力有限，一般用CPU个数进程，
lvs的负载能力要强于nginx，但功能上要弱于nginx，所以搭配使用效果更好.
haproxy的作者 解释 为什么LVS性能更好：
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.
http://www.intgoo.com/archives/56.html
不过lvs + KEEPALIVE + nginx配置起来还是蛮折腾的，有钱直接上F5吧。。。
