|
Hi Jinhua,
How do you think about the performance of the new L7 switching system?
Traditionally, the load balancer establishs a "pipe" between the client
and the selected real server. In other word, the load balancer acts as
a proxy. In this way, one TCP connection corresponds to two TCP
connections.
Why not try other new manners to ensure the low cost of L7 switch?
Besides, how do you think about the parallel workmode among the multiple
load balancers? That is, active & ative. I think it's meaningful to
improve
the Scalability of L7 switch.
You need to bridge the traffic in order to perform accurate layer7
switching decision especially for HTTP/1.1 where multiple requests are
sent into the same persitent connection. So L7SW must be a proxy but a
high speed proxy. I mean, with the current design, socket API is used in
order to have a compatibility layer with current proxy software and
proxy design, but as soon as the socket are spliced the socket context
for each connection is released. tcp_splice module create a layer4
forwarding rules, so packets are switched from on side to the other just
with the same performance as layer4 switching system (IPVS). We just
have context switching overhead induced by client GET request relaying
from client to server. Parallel balancing can be handled by an upper
layer4 balancing system (IPVS) to a pool of L7SW.
cya,
Alexandre
|
