Re: how to achieve URL hash LB algorithm on ZXTM

Hi Ben
one more question, based on my test, I found that after I restart squid on
one of my backend server,

zxtm would not hash the URLs back. that caused my backends are not equal to
serve requests.

now, the traffic between them are 4:2:1.

any thoughts?

thanks

Eric


On Fri, Jul 31, 2009 at 11:43 PM, Ben Mansell <[email protected]> wrote:

> Excellent news!
>
> It's difficult to say, in general, what impact TrafficScript has on
> performance, as it all depends on just what you are doing with it. Complex
> actions, such as performing big regular expression matches and data
> substitution, will use more CPU. The rule that you are using should have not
> much impact, as it is doing relatively little work, for instance.
>
> A key point though is that there is no "fast path" for HTTP processing that
> cannot be used when you start using TrafficScript, i.e. you won't take a big
> hit to performance when using small amounts of TrafficScript vs using none.
>
> Ben
>
> On 31/07/2009 15:24, Eric Y. Zhang wrote:
>
>> Thanks Ben
>> it works like a charm!! TrafficScript is quite impressive. any idea about
>> how TrafficScript impacts the performance of ZXTM?
>>
>>
>>
>> On Thu, Jul 30, 2009 at 6:33 PM, Ben Mansell<[email protected]<mailto:
>> [email protected]>>  wrote:
>> That is what it achieves. It does this by using a session persistence
>> mapping that picks a server to use based on the URL requested, and not on
>> the client.
>>
>>
>> Ben
>>
>>
>> On 30/07/2009 06:45, Eric Y. Zhang wrote:
>> thanks. but that is not what I really want. the trafficscript divided
>> traffic based on session, I want something like this
>>
>> www.abc.com/1.html<http://www.abc.com/1.html><http://www.abc.com/1.html>
>>   on squid1 permanently
>> www.abc.com/2.html<http://www.abc.com/2.html><http://www.abc.com/2.html>
>>   on squid2 permanently
>>
>>
>> Eric
>>
>> On Wed, Jul 29, 2009 at 5:19 PM, Ben Mansell<[email protected]<mailto:
>> [email protected]><mailto:[email protected]<mailto:[email protected]>>>   wrote:
>>
>> On 29/07/2009 00:48, Eric Y. Zhang wrote:
>> routing requests to different backend server in same pool.let's say, I
>> have 5 squid servers behind LB, if LB can do URL hash, then 1of squid server
>> only needs take 20% requests, that helps a lot.
>>
>> There are a few ways to achieve this. The first is to use the 'perceptive'
>> load balancing algorithm. This takes several factors into account when
>> choosing a node to use, including the URL of a request. However, it's only
>> one of many factors, so it doesn't rigidly enforce the URL->squid server
>> mapping that you probably want.
>>
>> What you can do instead is to leave the LB algorithm unaltered, and
>> instead use a session persistence class to dictate where each request goes.
>>
>> Create a 'Universal' session persistence class and assign it to your pool
>> of squid servers. This then lets a TrafficScript rule pick which squid
>> server to use. The TrafficScript command is:
>>
>> connection.setPersistenceKey( http.getRawURL() );
>>
>> ...and then requests with the same URL will use the same squid server.
>> However, this needs a bit of refinement. You are likely to have many many
>> different URLs going to your squid servers. Each different URL creates a
>> different session persistence mapping, and there are limits on the number of
>> these. To ensure that too many aren't used, we can 'hash' the URL into a
>> smaller set of sessions:
>>
>> # Hash the URL, then take the first byte, giving 256 different sessions.
>> # This also uses the website hostname, in case you are caching several
>> # websites.
>> $session = string.left( string.hashMD5( http.getHostHeader() .
>>                                        http.getRawURL() ), 1 );
>> connection.setPersistenceKey( $session );
>>
>> So, add this rule in, assign it to your virtual server and then your squid
>> traffic will be nicely divided up. This should improve the cache hit rates.
>>
>>
>> Ben
>> _______________________________________________
>> lb-l mailing list
>> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:
>> [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
>>
>>
>>
>> --
>> Life is hard
>>
>> _______________________________________________
>> lb-l mailing list
>> [email protected]<mailto:[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
>>
>>
>>
>> --
>> Life is hard
>>
>
> _______________________________________________
> 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
>



-- 
Life is hard

_______________________________________________
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