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
