>> 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.
Like Alex "prophesized" last 3 weeks we have been fighting with
"theoretical" people who are part the project, and who wanted to try some
very exotic load balancing schemes !!! :-))
But now that the project is again "practical solution" oriented I am back to
the programming part.
And on that note ...
>> 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").
Glad we have sorted this misunderstanding.
>> 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.
That is exactly why I am developing a mechanism for ICAP server/servers to
send their load parameters to Squid server/servers so that the "load" is not
assumed and predicted but exactly determined by the ICAP server and
advertised to "everybody that is concerned"
>> 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!
Both problems are solved with our proposed solution.
1. Servers will not gang up on the idle service because every ICAP
transaction will bring back a real-load parameter to every squid service.
That way every time adaptation is performed the real load of the particular
service will be known and the load table of the known services will be
updated in every squid/proxy server.
2. Overloaded services will advance on the list of services to be used at
the rate that there load is lowered.
3. The "quant of load" that is increasing the load parameter in squid
service will stop ganging on the particular service because the quant will
always be greater than the real load that the new request brings to the
server.
After the holidays I will be submitting some of the code/ideas for testing.
Until then
Good bye and Happy Holidays (whatever yours are :-))) )
Good luck,
Alex.
Received on Sun Dec 22 2013 - 18:35:35 MST
This archive was generated by hypermail 2.2.0 : Mon Dec 23 2013 - 12:00:13 MST