Re: CLIENT_SOCK_SZ

On Sat, Dec 22, 2001, Jon Kay wrote:
> Oh, and while we're arguing over old size limits starting with the
> digit 4 and mulling sadly over performance, let's talk about
> CLIENT_SOCK_SZ.
>
> 4096 was probably always a little on the small side, though. I guess
> it might reduce latency on them slow links. But it's smaller than
> most web objects. The median object size hovers around 7k, if I
> recall, and average object size has been oh so slowly creeping
> asymptotically down to 12k.
>
> 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.

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.

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.

Adrian
Received on Sat Dec 22 2001 - 19:09:48 MST