On 12/05/2013 01:13 PM, Goran Slaviæ wrote:
>> Alex: Please note that Squid already supports a primitive form of ICAP load
>> balancing using a combination of "adaptation_access" and "random" ACL.
>> It is possible to balance accesses to ICAP services by using appropriate
>> adaptation_access match probability. For example, for even balancing of
>> accesses to 3 services, the random match probabilities should be 1/3, 1/2,
>> and 1.
> As I already answered Amos, that load balancing (on the random principles)
> only works if the number of connections is relational to the workload of the
> adaptation service/server.
This is probably just a terminology gap, but I do not think the
supported random solution is related to connections. IIRC, the ICAP
service is randomly picked for each new ICAP _request_, not new ICAP or
HTTP _connection_. It should work well for workloads where services
receiving similar number of ICAP requests have similar loads (either
because individual requests have similar performance "cost" or because
aggregated requests have similar aggregated "cost").
Your solution should address situations where similar number of ICAP
requests have significantly different costs (either because individual
requests "cost" varies too much or because some external factors slow
down some services but not the others). This will cover most use cases.
The other set of use cases that I boldly predict might eventually become
popular is when multiple independent proxies are accessing a set of
similar ICAP services. For example, many small ISPs accessing a set of
3rd-party AV services. Today, this already kind of happens when an SMP
Squid is configured to use a set of similar ICAP services.
The challenge in this "other set" is to avoid multiple proxies all
abandoning an overloaded service and then all ganging up on an idle
service, resulting in overload/underutilization waves that decrease
overall performance. Solving this may require each ICAP service to load
balance its proxies, essentially!
I know you are working on a research project, but it would help if you
focus on common interesting cases rather than esoteric anomalies where
some research algorithms often thrive, especially if you want your
changes to become a part of the official Squid distribution.
> Also I tried the said primitive form of load
> balancing and it had some rather unfortunate consequences (some services
> went "down" and where not recovered, others where underused .)
The supported random solution does not work well when individual
services may become overloaded while receiving a similar number of
requests. I hope your solution will solve that problem.
Good luck,
Alex.
Received on Fri Dec 06 2013 - 16:08:55 MST
This archive was generated by hypermail 2.2.0 : Sun Dec 22 2013 - 12:00:11 MST