URL Hashing + Sticky, not optimal.

[shukla1975]

Gurus,

Had just deployed an ACE for my customer for the caching servers.

We used URL hash and Sticky , after some monitoring we find that 1 server gets 15K connections, another one gets only 5K.

Now its to be understood that due to the erratic internet behavior of users the URLs cached are getting accessed in this disproportionate way.

Now, for cache servers the URL hash is the best predictor, can we try anything else or its going to be as it is.

Have advised for "application request/response predictor" for in case the servers get loaded beyond a point.

let me know your views.

Cheers

Shukla.

[Gilles Dufour]

you have to understand the reason of url hash.

The goal is to guarantee that the same object will not be cached on mayne servers and therefore maximise disk usage.

So, if you don't really need to maximise this disk usage, you could use any other balancing method.

There is not one-best-for-all solution.

It all depends on what are your priorities.

Gilles.

[shukla1975]

Gilles,

yes i understand the method involved, thus looking to get some tweaking to disallow any server stalling due to higher number of connections.

still monitoring it on the cleint test-bed.

regards

Shukla.

[Gilles Dufour]

you could configure a maxconn value so that the server is not being used once this value is being reached.

Taking your example, I would set a maxconn at 10,000.

Gilles.

[shukla1975]

Gilles,

Appreciate your reply, had advised the client the first time, still will havent tried ..

couple of things :

1. If i do max-conn with URL hashing, if user-A is going for url-A which is in cache-A and ACE has reached its max-conn value, will it for the same URL direct is towards cache-B with a new entry of url-A (which will in turn start making multi servers cache the same URL bcos of max conns) ??

2. the second hash method we proposed was for "applic request/response" , im not sure how this predictor will work or be beneficial against URL hash.

and im hunting for a doc which explain these predictors in depth ... not just the definitions. As such insights give u an edge when u don't have a test bed for yourself.

awaiting optimistically.

Cheers

Shukla.

[Gilles Dufour]

Shukla,

1/ yes, once max-conn has been reached by one server we stop using it and therefore the same content will eventually exist on multiple servers.

This solution does not give you perfect loadbalancing or perfect cache optimization but a bit of both.

2/ this is no hash method.

We just measure the server response time from the moment we sent the HTTP request to the moment we receive the server response.

You don't get the cache disk optimization anymore.

If you don't need to maximise disk usage, you could use any other method and leastconn is usually giving good results.

But I kind of understood you wanted to preserve disk space on your caches.

Gilles.

[shukla1975]

Gilles,

today we removed sticky connections from URL hash, thus, our both caches were getting equal amount of requests, but need to see if it works fine for some time or now.

Typically, we would like to have all the caches to be utilized "almost equally" in terms of number of connections, CPU utilizations, disk usages etc...and also to have good response time for clients.

Does ACE give any extra benefits from other LBs or is it just a scaled up version of legacy LBs ?

need to position it strongly.

will keep bothering :-))

Cheers

Shukla.

[Gilles Dufour]

Currently the ACE Blade is just a LB with some FW features.

The ACE appliance (C4710) does offer more features since it comes with the AVS with option like compression, caching, flashforward, ...

Gilles.

[shukla1975]

Gilles and ACE-experts,

We have now removed stickiness from the ACE and have only URL hashing as the predictor.

Now we have 1 cache at 350Mbps traffic and the second one with 600Mbps..client is now concerned with these stats.

IMHO ,as the predictor is URL hash, one cache is getting higher traffic from various sources to the same URL(s) than the other even though we don't have stickiness configured.

let me know any other possible reason for this erratic user traffic pattern.

need to nail this issue soon.

Cheers

Shukla.

[Gilles Dufour]

This is not a technical issue.

This is the way it is with the configuration you have chosen.

For example, every user in the world will probably go to www.google.com.

So, this url will be hash to a server which will always be same and this server will see more requests than the others.

This is just a basic example to show you that hashing can't guarantee to have equal BW to the servers.

If the primary concern is the BW and not disk space, you need to go to roundrobin or leastconn.

If your goal is to preserver disk space, your solution is the best one and the drawback is unequal BW.

You can't get both at the same time.

Gilles.

[shukla1975]

Gilles,

I agree to your justification Gilles, its that you would like to be sure before you make that a commandment in front of the customer.. :-)

Now for the same setup i believe that a dest-ip based a LB would do some justice as for the URL having multiple IP addresses ,we would have the traffic being distributed to some extent to different cache engines.

let me know if you have some tech-tips !

cheers

Shukla.