On 19/02/2012 9:40 a.m., Clement Game wrote:
Hi,
This is my first post on the squid-users mailing list and as an introduction i'll start with a few questions on the squid icap client :)
1. Why was the balancing mechanism removed from the icap client ( starting from 3.x i think, didn't read the changelogs recently ) ? Now i have to delegate icap balancing to a local HAProxy instance, which is less convenient even if HAProxy works great.
Squid 2.x and older have *no* ICAP support, so I'm not sure what you are
talking about there. Something cannot be "removed" if it was never yet
supported.
Squid-3.0 was the first to add ICAP support, and as such it was fairly
limited and only did what the sponsors needed it to do. As time
progressed more ICAP feature support was added. As of this writing the
most current stable Squid release is 3.1.19.
As for load balancing. AKAIK, due to network state overheads being worse
than CPU overheads there is better performance when sending traffic to
one backend (which already has the state on hand) than splitting it
between two or more (fresh state lookups for each). ICAP in Squid
utilizes this behaviour by loading one service processor up to its
capacity as determined by the OPTIONS reponse Max-Connections header.
With a backup mechanism measuring and balancing on response time in case
someone set that limit too high or not at all.
2. when having multiple ICAP services configured in squid, and considering that each of them can potentially alter the content of requests/responses, is there a way to decide if the services must be chained, or queried asynchronously ? the good thing would be to be able to set this behavior for each icap service configured.
You can.
If its been a while since you read the documentation you may want to try
catching up on the 3.1 ICAP developments before you get any more questions.
http://wiki.squid-cache.org/Features/ICAP
The "way to decide" you ask about is the static/dynamic chaining that
documentation talks about.
Amos
