Re: Introduction

On 27/11/2013 8:37 p.m., Goran Slavić wrote:
> My name is Goran Slavic,
>
> I am currently writhing a masters theses on Faculty of Electrical
> Engineering - University of Belgrade (Serbia).
>

Welcome aboard!

Please take a few minutes to get acquainted with the project's current
best practices, both in terms of coding conventions and code
submission guidelines. You can find many documents in the wiki. The main
documents for beginner Squid developers are linked from
http://wiki.squid-cache.org/DeveloperResources and
http://wiki.squid-cache.org/MergeProcedure.

> I am interested in developing "a true" load balancing feature
> between ICAP adaptation servers. As I see it, current configuration options
> for adaptation servers only provides failsafe in case of ICAP server
> failure. I am interested in developing a load balancing mechanism which will
> allow squid to share adaptation load between multiple ICAP servers not only
> according to number of connections to those servers but also according to
> server load of the used ICAP servers.
>
> If the above mentioned feature is already planed / developed - I
> would gladly contribute to the effort. If it is not in development - I have
> no problem starting the work "from scratch" / or from the current
> development stage (of course with the help/guidance from the development
> community).

The Measurement Factory are our main development group working on and
with ICAP. I am not aware of any work in this direction currently but
you should seek out their knowledge as well for better accuracy on the
situation. Alex Rousskov is the main contact person we have there.

I seem to recall load balancing other than connection based having some
issues which have not been adequately resolved yet (although solving
these directly are more like Phd level problems IMHO, so you may want to
discuss the choice and scope of project with your advisor in light of
these and Measurement Factory feedback).

* How are you defining "load"? CPU? memory? traffic bytes? request count?
 - as you point out this is currently based on connection count. However
that is because the head-of-line blocking embeded in the protocol syntax
results in no one connection transfering more than one request
simultaneously. Thus the per-request load and CPU processing load are
directly relational to the in-use connection count on that service.

* One ICAP service may be shared with multiple proxies. How do you
intend to communicate the load metrics to all of them to prevent making
overloading worse?
 - under connection-based balancing this is done by the ICAP server
dynamically updating its max-connecions value in OPTIONS requests to
each one.

* How do you propose to solve the problem of connection timeout and
starvation?
 - As I understand it ICAP traffic is off-balanced towards a
primary-secondary service design rather than round-robin or such in
order to keep as many connections active as required. Thus avoiding idle
timeouts, connection closure races and TCP setup costs renewing connections.

* How do you propose to solve the problem of ICAP server conext switching?
 - The primary-secondary design also causes the primary server software
and memory to remain active as constantly as possible in the ICAP
server. Thus preventing the servers OS inadvertently swapping inactive
memory out and reduces delays re-loading it.

HTH
Amos
Received on Wed Nov 27 2013 - 09:00:18 MST