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.
