Re: [squid-users] Has anyone heard about this option??

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 09 Oct 2013 14:42:42 -0600

On 10/09/2013 01:38 PM, Eliezer Croitoru wrote:
> I was sitting trying to figure out what every config directive of squid
> does. I starte reading again and again And then I see:
> http://www.squid-cache.org/Doc/config/read_ahead_gap/

As you probably know, the option is supposed to limit internal Squid
buffering of the incoming response bodies being sent to the client.

> Why would I need that anyway? wont my little 3.X ghz machine will do all
> the tricks?

The CPU speed and system software outside Squid are pretty much
irrelevant in this context. Think of a pool with two pipes: server pumps
data into Squid (in) and client pumps data out of Squid (out). The Squid
buffer is the pool between them. Ideally, you want the pool filled with
water but not overflowing.

> So I tried to understand what some code means etc.
> Can anyone tell me what is this directive good for? why would I need a
> read_ahead if the network between the proxy and me is OK?

The buffer is needed regardless of the network speeds. Relatively slow
(compared to the server) client network may indeed require larger
buffers for better performance, but there are other factors affecting
optimal buffer sizes.

In one extreme case, consider a malicious client requesting an
infinite-size object from a fast server while reading just 1 byte every
minute to keep the transaction alive. Without the buffer size limit,
your pool will soon overflow. The opposite extreme is a client so slow
or so poorly connected that it cannot fetch the response before the
origin server times out. Both cases occur in real deployments.

Squid could hard-code the maximum buffer size (i.e., the read ahead
gap), but deployment environments differ, and sooner or later somebody
would want a different size value. That is why it is a configuration option.

HTH,

Alex.
Received on Wed Oct 09 2013 - 20:43:00 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 10 2013 - 12:00:05 MDT