LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [PATCH-2.5] spelling fixes

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH-2.5] spelling fixes
From: Roberto Nibali <ratz@xxxxxx>
Date: Fri, 11 Jul 2003 13:56:30 +0200
Hi Wensong,

I think that it depends on what the overflow pool is for. If the overflow
pool still provides the service as the normal server pool, we have to
consider the persistency feature for the overflow pool, because the

Why would anyone do this? But I agree the functionality has to be preserved.

network services may require persistency. If the overflow pool is only to show pages that "The system is busy, please come back later", then it is easy to do, we don't need consider the persistency for overflow pool.

And also no threshold limitation.

Maybe users will mostly use the second one. Anyway, we need think more about it and make a decision

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.

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.

Best regards and thanks for your time,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

<Prev in Thread] Current Thread [Next in Thread>