|
Hi Ratz,
On Fri, 11 Jul 2003, Roberto Nibali wrote:
>
> There are more problems coming :):
>
> I did some investigations on HTTP/1.0 and HTTP/1.1 with pipelining on GET and
> HEAD requests and the way we currently decide for IP_VS_F_DEST_OVERLOAD is
> maybe
> not intelligent enough. Currently we do a 'session = x + y' approach, where x
> is
> active and y is inactiv connections.
>
> The problem is that if 10 clients surf a dynamic web page using HTTP/1.0 with
> some gifs (lets say 10) and db requests and 1 client is fetching the same
> page
> using HTTP/1.1 we will count 10*10+1 sessions for 11 clients fetching one
> page
> once. In such a case the inactive connections are weighted to much. It would
> be
> nice to have following approach: session = a*x + b*y, where the a,b
> parameters
> can be set via ipvsadm.
>
Well, please don't make things complicated. IPVS only works on layer-4,
cannot balance the load well among the servers for all the situations. For
example, if there are active connections, some may have other traffic, and
some may be idle; some may cause the server run big tasks, some may just
run small tasks. Maybe a lot connections of bit tasks are sent to the same
server, it cause the server overloaded, though the number of active
connections to the server is less than that of other servers.
For well-balanced solutions, it is good to use dynamic-feedback weight
adaption in the user-space.
> BTW, we have the hprio scheduler active now plus some fugly hack for the
> masquerading timer (why can't we reset the slow timer for masq entries in
> 2.2.x
> in a normal way???). The hprio scheduler offers some new cool setup solutions
> which I will write down and make a proposal. With it you can have higher page
> request starvation granularity.
>
> We'll discuss the open points at OLS with Lars, Horms, Joe, whoever joins. If
> you want us to discuss anything else, let us know.
>
> As you've probably seen, Linus has announced the 2.6.0-test series with the
> last
> 2.5.x kernel. I guess we need to hurry up a little with inclusion or think
> about
> a good reason in case of later inclusion. Maybe we do add the overflow pool
> server mechanims first and will then submit for inclusion.
>
Yes, it's probably good to ask now, we will add the overflow pool later.
Cheers,
Wensong
|
