On Mon, 31 Jan 2011 10:57:57 +0100, "Jack Falworth" <jackf.mail@xxxxxx> 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
