Re: Re : serveriron predictor

"Reynald Mahinay" <[email protected]>
Newsgroups gmane.comp.programming.load-balancing.general
Message-ID <[email protected]>
Hi Rubens,

You are dead on  correct on DSR issue with response time. Ah well, I can pretty much say the only options I have are;

1. use weighted predictor
2. use server response time weights
3. or used either of the two above in combination of "max-tcp-conn-rate".

Thanks,
Reynald



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Rubens Kuhl
Sent: Wednesday, June 24, 2009 12:50 PM
To: Load Balancing Mailing List
Subject: Re: [load balancing] Re : serveriron predictor

Reynald,

Haven't tried that one, because DSR (Direct Server Return) makes the
response times available only to the health checks, not to every
connection.

As you have a dynamic parameter I think it's still a good to thing to
use max-tcp-conn-rate per server in order to prevent too much "boat
swinging".

Also, Foundry docs list a "smooth factor" for use with response-time
that is likely to boost stability.


Rubens



On Tue, Jun 23, 2009 at 10:35 PM, Reynald
Mahinay<[email protected]> wrote:
> Hello Surya and Rubens,
>
> You both have a good point. In relation, I look-up the net and found serveriron can do something like response-time + weighted servers. It's like combining the two predictor you guys have suggested.
>
> Have you tried that setup before?
>
> Regards,
> Reynald
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Rubens Kuhl
> Sent: Tuesday, June 23, 2009 10:57 PM
> To: Load Balancing Mailing List
> Subject: Re: [load balancing] Re : serveriron predictor
>
>>   least-conn
>>   least-local-conn
>>   least-local-sess
>>   local-weighted
>>   response-time
>>   round-robin
>>   weighted
>
> I suggest the weighted predictors. Heavy loads are prone to cause
> instability with response-time or least-conn, with the server that was
> most responsive been killed by the next wave of connection setups that
> will all go to that server.
>
> Unless the balancer can override this behavior with a max new
> connection per second rate, I advise to use static balancing, weighted
> by the effective http power(measured with ab or your favorite http
> load tool), not simple CPU clock math.
>
>
> Rubens
> _______________________________________________
> lb-l mailing list
> [email protected]
> http://vegan.net/mailman/listinfo/lb-l
> Searchable Archive: http://vegan.net/lb/archive
> http://lbdigest.com Load Balancing Digest
> http://lbwiki.com Load Balancing Wiki
>
> _______________________________________________
> lb-l mailing list
> [email protected]
> http://vegan.net/mailman/listinfo/lb-l
> Searchable Archive: http://vegan.net/lb/archive
> http://lbdigest.com Load Balancing Digest
> http://lbwiki.com Load Balancing Wiki
>
_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.