From: Jon Kay <>
Date: Sun, 23 Dec 2001 00:34:30 -0600

Adrian Chadd wrote:
> On Sat, Dec 22, 2001, Jon Kay wrote:

> > How about if we raise CLIENT_SOCK_SZ to 16k so that when under load,
> > Squid can do most of 'em in one fell sweep through the processing
> > stack?
> Have you tried doing it? it works, but it doesn't give you the
> benefit that you may think.

I'm expecting only 4-5% improvement, but if we can get in ten 4-5%
improvements, then we have a much better piece of software. And this
one is so easy.
> Its used as the copy size for stuff from storeClientCopy().
> SQUID_TCP_SO_RCVBUF is the variable which defines how big a buffer
> is passed to read(), and this is system dependant (I set my recvbufs
> under FreeBSD to 64k, so its 65536..)
> The real problem is the whole storage manager with its 4k pages.
> You can't easily up that though - I've tried, and you end up wasting
> so much damned memory.

What we really need to add to the storage manager is the ability to
storeAppend an already-allocated, already-filled buffer that will just be
pointed to by the mem_node structure, like they do it in the kernel.

Although in that case we wouldn't want to raise CLIENT_SOCK_SZ about 8k.
But it would be paid for in full by the reduced copying overhead.
> I'm all for upping CLIENT_SOCK_SZ to 16k. HOw about doing some polygraph
> testing to see any benefits? I did it myself .. about a year ago, so I
> forget exactly what happened.

I'll try and get them in. I want to set up polygraph anyway for some leak
testing on the push branch.

Jon Kay                                         (512) 420-9025
Squid consulting				  'push done right.'
Received on Sat Dec 22 2001 - 23:36:24 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:41 MST