Re: [squid-users] TCP send/receive buffer tuning

On Mon, 31 Jan 2011 10:57:57 +0100, "Jack Falworth" <jackf.mail_at_gmx.de>
wrote:
> Hi squid-users,
>
> I have a question regarding the TCP send/receive buffer size Squid uses.
> For my high-performance setup I increased both buffer sizes on my Ubuntu
> 10.04 system. Unfortunately I found out that Squid 2.7 (as well as 3.x)
> limits the receive buffer to 64K and the send buffer to 32K in the
> configure.in script.
>
> In addition I found this bug report regarding this check:
> http://bugs.squid-cache.org/show_bug.cgi?id=1075
>
> I couldn't really figure out the problem with Squid using higher buffer
> sizes if it is the intention of the administrator to increase those
values.
> This check was included in CVS rev. 1.303 back in 2005, thus it's quite
> old.
>
> Is this some legacy check or is it still important with today's systems?
> Can I safely remove this check or will this have some side-effects, e.g.
> say the some internal data structures won't be able to cope with higher
> values?

Note that setting ONLY affects the TCP buffers so 64K worth of packets can
sit outside of Squid in the networking stack.
This has side-effects on the ACK packets. While they are waiting in that
buffer they are possibly ACKed but not actually received by Squid. If
anything causes Squid to stop, crash or slow down on its read()'s and
accept()'s the client can be left with incorrect information about the
state of those bytes.

There is a separate problem internal to Squid-3.x which may be hitting you
harder than the TCP stack size. By default we set Squid to pull a minimum
1KB. Unfortunately if the client is fast enough to read all of that reply
and empty the buffer before the next server read there is no reason for
Squid to grow it beyond 1KB, so is left with a relatively slow cycle doing
small 1KB hunks. We are still looking for a good way to avoid this and make
the server reads grow for larger objects.

Amos
Received on Mon Jan 31 2011 - 22:53:34 MST