Re: [squid-users] Two Squid with common cache

Hi Amos,

>> This thread just raised another question on my mind. How would adding
>> another instance (in the same box) with "null cache_dir" improve my
>> performance? I'm a bit confused. Could you please explain a bit more?
>
> I don't think it would improve performance per-se. It would meet your
> criteria of "i would like the cache_dir to be common between the 2 squid".
>

Exactly, as on-disk objects will be served by Squid A alone. And, but
objects in Cache_Mem will be served by Squid A or B from their own
respective memory allocations, and TCP_MISS entirely served from the
Internet (assuming Squid A is not configured to fetch from internet for
ICP_MISS).

> Two squid running on the same box:
> Squid-A has a large on-disk cache_dir
> Squid-B has no disk cache, and sources all requests from Squid-A.
>
> The overall effect is that only one copy of each cached object is held on
> disk at that machine (in Squid-A's cache).
>
> Since Squid-B passes on most requests to Squid-A, the actual response is
> less than 2x, more like: up to 1.5x capacity of only squid-A.
>

I didn't get this increase of "Capacity". Also, what do you mean by
"response"? Response Time? Can you explain a bit more?

> It's up to you if the loss of ~25% response capacity is worth the
> duplicate object removal.
>

I'm stumped on this one too. Can you please also educate me on "Response
Capacity" and "Duplicate Object Removal"?

> There is no net gain in response timing, since the Squid-B -> Squid-A
> request + Squid-A disk read, is usually slower than a disk read.
>

This I understand clearly.

> Off to performance:
> for best performance, you cache small objects into COSS directories and
> tune AUFS/DiskD to the OS type you are running on. Ensuring only one disk
> spindle is used per cache_dir with as fast disks as you can buy. Size
> doesn't matter, speed does.
>

Yes, exactly as you and other gurus in the forum have said that in numerous
posts. On this note, I have seen that COSS has minimal impact on disk
usage, almost negligible. And, I also read somewhere, that Linux usage of
in-memory disk buffers is quite efficient. So, which is more efficient -
Squid's "cache_mem" or OS's in-memory disk buffer?

> Then pump up the machine memory as far as it can go and allocate as said
> many bytes to cache_mem as possible without causing any memory swapping
> (particularly prevent swapping when under highest load).
>

How do you find out if the system is "swapping"? We already have configured
the Linux box to have NO swap space.

We have the following in each of our Squid boxes:
4 x 250 GB SATA HDDs each having:
- 20 GB COSS with max-size=1000000 maxfullbufs=32 membufs=256
block-size=2048 max-size=65536
- 160 GB aufs with min-size=65537

So, does that mean the Squid process needs 10 GB [(14MB / GB) x (180 GB per
disk) x 4 disks] of memory just to maintain the index? And, on top of that
the size of "cache_mem" that we specify in our config? And, also on top of
these, some space for disk buffers?

Regards
HASSAN
Received on Fri Mar 06 2009 - 13:31:30 MST