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
|