Re: CLIENT_SOCK_SZ

On 23 Dec 2001, at 0:34, Jon Kay <jkay@pushcache.com> wrote:

> 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.

 larger transfer chunks makes most sense in context of triangle:
 client --T-- server
          |
        disks

 It does make a huge difference when you transfer large file from fast
 server to fast client. By upping transfer size, you avoid lots of
 overhead of OS/squid switching, kernel<->userland copying, help disk
 efficiency, drastically reduce number of polls with immediate returns.
 This translates into much lower cpu utilisation and higher bw, also
 I think imposes less load-overhead onto TCP stack of OS.

 Increasing client side buffering alone gives little to nothing. We
 need complete path to be upped, especially disk path. This was simple
 way back, and proved to have noticable effect, but afaik its not that
 easy in current HEAD.

> > 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.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Mon Dec 24 2001 - 01:54:54 MST