Re: CLIENT_SOCK_SZ

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        pushcache.com                      jkay@pushcache.com
http://www.pushcache.com/                             (512) 420-9025
Squid consulting				  'push done right.'