Squid Proxy Configuration

Description
This describes the algorithms used for the above tags.

INCOMING sockets are the ICP and HTTP ports. We need to check these fairly regularly, but how often? When the load increases, we want to check the incoming sockets more often. If we have a lot of incoming ICP, then we need to check these sockets more than if we just have HTTP. The variables ‘incoming_icp_interval’ and ‘incoming_http_interval’determine how many normal I/O events to process before checking incoming sockets again. Note we store the incoming_interval multiplied by a factor of (2^INCOMING_FACTOR) to have some pseudo-floating point precision.

The variable ‘icp_io_events’ and ‘http_io_events’ counts how many normal I/O events have been processed since the last check on the incoming sockets. When io_events >incoming_interval, its time to check incoming sockets.

Every time we check incoming sockets, we count how many new messages or connections were processed. This is used to adjust the incoming_interval for the next iteration. The new incoming_interval is calculated as the current incoming_interval plus what we would like to see as an average number of events minus the number of events just processed.

incoming_interval = incoming_interval + target_average – number_of_events_processed.

There are separate incoming_interval counters for both HTTP and ICP events. You can see the current values of the incoming_interval, as well as a histogram of ‘incoming_events’ by asking the cache manager for ‘comm_incoming’, e.g.:

% ./client mgr:comm_incoming

Caution
-We have MAX_INCOMING_INTEGER as a magic upper limit on incoming_interval for both types of sockets. At the largest value the cache will effectively be idling.

-The higher the INCOMING_FACTOR, the slower the algorithm will respond to load spikes/increases/decreases in demand. A value between 3 and 8 is recommended.