Nyamul Hassan wrote:
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?
"request capacity" On a given CPU squid has a maximum absolute number
of requests per second it can process.
Using two squid in parallel load-balanced doubles that maximum
req/sec, assuming the load balancer can handle it too. This setup with
one as parent gets less than 1.5x (half-again) instead of 2x (double).
Is there a measure on this "Maximum Absolute Number" of requests?
Not really. Benchmarking info has been hard to come by. I guess any
given machine and squid version would fit somewhere between 600rps and
5,000 rps in one Squid.
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"?
capacity as above.
"duplicate object removal" having only one cache of objects instead of
two.
On the "duplicate" note, if you've got sibling proxies configured as
"proxy-only", that should minimize duplication, as anything that Squid A
sees on Squid B is served from Squid B, with Squid A not doing any
caching of that content. The only duplicate that I can think of can
happen in case of simultaneous requests of the same object to both Squid
A and Squid B, and which is not yet cached in either of them, which
shouldn't be much.
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?
Ah, one of the really big questions.
Looks like we have yet to find out a suitable answer to that! Is there
a way to test this? Like say, having no "cache_mem", and seeing how far
we can push this, and getting comparable readings on IO_Wait and sevice
timers?
Indeed. I'm hoping that a lot of things like this will be easier to test
in isolation once they have been broken out of the current mesh of code
and into sub-libraries. The SourceLayout project is working towards that
right now.
Someone should be able to begin some serious performance testing of
components in 3.2.
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.
Now that I'm not sure of myself. Never having faced that much server
load.
Well, in our case we've got only 8 GB of RAM, and cache_mem is set to
3GB. Squid process shows it is consuming ~4GB of memory (in top).
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?
I believe so. Yes.
Looks like we really need to move to 16 GB of memory!
Regards
HASSAN
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
Current Beta Squid 3.1.0.6
