LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [PATCH] Invalidate expired persistance templates

To: Horms <horms@xxxxxxxxxxxx>
Subject: Re: [PATCH] Invalidate expired persistance templates
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Tue, 6 Dec 2005 02:40:37 +0200 (EET)
        Hello,

On Mon, 5 Dec 2005, Horms wrote:

> I think that you are confused about what I am trying to do,
> or perhaps I am confused about what I am trying to do.
>
> The idea of my patch is not to change the persistance sementics.
> It is mearly to fix the case where the template expires and
> still has controlled connections. The current code will change
> the persistance timeout if this occurs. And that persistance template,
> whith the new timeout, can continued to be used for new connections
> and existing.  Even though its timout is not the user-specified value.
> Which is just plain weird.

        Yes, that is why your patch that does not change cp->timeout
at all is more valid for such example:

i'm browsing https site, reading some docs before deciding to
fill 3 forms. Persistence is set to 15 mins (5 mins for each form).
So, the timing is:

+00min: i'm starting to read docs, reading 10mins
+10min: starting to fill form 1 for 4 mins (i'm fast)
+14min: posting form 1, starting to fill form 2 for 5 mins (normal)
+15min: invalidate broke my persistence because 15min persistence
expired while there are no connections, even if my last posting
was 1min ago and this conn expired
+19min: posting form 2, starting to fill form 3. What happens is that
this web form goes to another real server because first template
is invalidated or marked as expired

        What i want to show you is that the semantic "persistence
timeout covers period from first connection" is "just plain weird" :)
What i would want is persistence timeout to be large enough to
cover the idle periods between connections part from session. In
this example, i think 15mins is enough for my web site to allow
users to fill the web forms. The current timeout of 60 seconds
can be short too, that is why I say your patch that will extend
persistence with another 15mins is more correct. What is the
benefit to invalidate the persistence exactly at its defined period?
It helps the load balancing? Or just saves memory? I would care
for proper web form posting to single real server. How can i
select this behavior?

> > 3 seconds is very low value, it can create load.
>
> I don't really mind what value it is, perhaps 10 seconds would
> be more appropriate. The current 60 value seems a little high to me.
> What do you recommend?

        Original user-defined value or user-defined extent

> > Better one to call ip_vs_conn_expire_now for ct
> > when its n_control reaches 0, eg. in ip_vs_control_del.
>
> I don't really think that is desirable at all. Won't that
> cause the persistance template to expire regardless of if
> its timeout has expired?

        Yes, in this form it is bogus

> You have stated on several occasions that invalidating
> the hash template using that method will break connections.
> So surely its a bad idea.
>
> The idea of IP_VS_CONN_F_EXPIRED is just to make sure that the
> template will not be used for any new connections. Existing

        That is what i don't want for my example, my session is
redirected to different server.

> connections will continue on as normal. Although they will
> almost certainly be in the FIN_WAIT state. Although I guess
> this semantic is broken if they aren't in that state.
>
> Perhaps a better idea, which I was thinking about this morning,
> is to change the timeout value, to say 60*HZ in ip_vs_conn_expire(),
> as per the existing code.  But always reset it to svc->timeout
> when it is used to create a new connection, so if it had timeout
> out, but ends up being used again, its timeout will be the
> user-defined value when it is re-used.
>
> I think this patch has racy access to ct->timeout,
> but it gives you an idea of what I am thinking about.

        This is a good idea, in this case setting 10 seconds in
ip_vs_conn_expire for templates is not so bad. Also, we should
take into account that the ip_vs_control_* mechanism is used from
FTP, may be just to extend the TCP EST period for the control conn
while there are DATA transfers.

> diff --git a/net/ipv4/ipvs/ip_vs_core.c b/net/ipv4/ipvs/ip_vs_core.c
> index 1a0843c..18b5e22 100644
> --- a/net/ipv4/ipvs/ip_vs_core.c
> +++ b/net/ipv4/ipvs/ip_vs_core.c
> @@ -283,8 +283,6 @@ ip_vs_sched_persist(struct ip_vs_service
>                                                   dest);
>                       if (ct == NULL)
>                               return NULL;
> -
> -                     ct->timeout = svc->timeout;
>               } else {
>                       /* set destination with the found template */
>                       dest = ct->dest;
> @@ -337,8 +335,6 @@ ip_vs_sched_persist(struct ip_vs_service
>                                                   dest);
>                       if (ct == NULL)
>                               return NULL;
> -
> -                     ct->timeout = svc->timeout;
>               } else {
>                       /* set destination with the found template */
>                       dest = ct->dest;
> @@ -346,6 +342,7 @@ ip_vs_sched_persist(struct ip_vs_service
>               dport = ports[1];
>       }
>
> +     ct->timeout = svc->timeout;
>       /*
>        *    Create a new connection according to the template
>        */

Regards

--
Julian Anastasov <ja@xxxxxx>

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