Am 01.02.2011 23:03, schrieb Amos Jeffries:
On Tue, 01 Feb 2011 14:31:02 +0100, Jack Falworth<jackf.mail@xxxxxx>
wrote:
On 31.01.2011 23:53, Amos Jeffries wrote:
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.
But this could also happen on a 64K buffer. If Squid crashes or goes
down for some reason then information is lost anyways.
Thus the only reason increasing the buffer size in a high-traffic
scenario would be a bad idea is if Squid is somehow overloaded and
slowed down on its read()'s and accept()'s? But if I make sure that
Squid can handle some peak traffic values without being overloaded it
would be safe to increase buffer sizes?
It's the only reason I'm aware of. There may be another I'm not.
Feel free to experiment and see for yourself of course.
Amos
I digged a little bit deeper and found some problems that would occur
when increasing the receive buffer.
The receive buffer size is stored in SQUID_TCP_SO_RCVBUF. There are some
code parts where this size is assigned to size_t variables which are
normally 16bit sized. If greater value are assigned the size
would wrap around. Critically parts are in the functions httpReadReply
(http.c), sslSetSelect (ssl.c) and clientEatRequestBodyHandler
(client_side.c).
So in my opinion there is no way to get this working without (some) code
rewrite and verifying these critical sections. Correct me if I'm wrong.
