Re: SQUID I/O

On Thu, 4 Dec 1997, Henrik Nordstrom wrote:

> Hirohisa TANIGUCHI wrote:
>
> > I've checked the packets go to and fro with tcpdump on the host which
> > runs Squid, and it seemed to me that no buffering is done when it
> > sends data to the client. (i.e. when it receives one packet from the
> > WWW server, Squid seems to send it immediately to the client without
> > buffering.)
>
> Squid is designed to behave this way. The idea is to introduce as small
> delays in the communication as possible.

This is certainly true. However, Squid does not have much control over the
sockets/TCP stack. In other words, it may think that the data is sent to
the client when, in fact, it is buffered in the TCP socket output buffer.

Since even a half empty the buffer is flushed automatically within a short
delay (as far as I understand), it is hard to notice the influence of the
buffer for misses on _slow_ outbound connections.

Hits are often a completely different story because they could be
retrieved from disk _fast_. In fact, _significant_ savings in proxy reply
time time of a hit versus a miss happen when the size of an object is
smaller than the socket buffer! In other words, if there is a hit for a
"big" object, the reduction in proxy reply time is not so big compared to
a reduction on a smaller hit (you still save a lot of outbound bandwidth
though).

Here are some figures proxy _reply_ time from our profiling collection
that show the influence of the TCP socket buffer:

http://www.cs.ndsu.nodak.edu/~rousskov/research/cache/squid/profiling/stats/gindex.all.wd/gbag.distr.cortvsz.html

Look for a "jump" in proxy response time at 16, 32, or 64KB point (those
are typical values for the socket buffer size, maximum is 64K). Visible on
most of the proxies we have studied. The collection also has similar
graphs for _total_ response time.

Alex.
Received on Thu Dec 04 1997 - 06:58:25 MST