Re: RAID or multiple cache_dir s?

Hi Paul,

> o For a reasonably well used cache, is using multiple cache_dir entries and
> efficient as a hardare RAID-0 box? (Yes I know there will be some
> small performance loss, but will squid make use of all the disks
> efficiently?)

Using multiple cache dirs is much preferable to using RAIND-0: Raid 0
doesn't have any redundancy, so you lose your complete cache if a single
disk dies. Using multiple cache dirs, you just lose the data stored on that
single disk. Squid spreads data evenly over all the tisks, so performance
should be ok in normal configuration. One difference is that a single file
gets stored to a single disk by squid, so if you've mostly got requests for
very large files raid would be better.

> o Another thread asked the question if a disk (and thus a cache_dir) went
> bad would squid continue to perform well using the remaining disks ?
> Is this true?

Quite true. I just had one of my 8GB Cache disks die; first I had the cache
running with reduced capacity for a few days and then I added a new drive.
Losing the disk reduced my hitrate of course, but the cache still performed
flawlessly, and quickly refilled the new disk when it became available.

> o Whats the maximum limits on Squid? Should I continue to throw disk at a
> box, or buy a separate box. If I can save on RAID, I can afford extra
> memory and so have a 1Gb RAM box - Squid won't break?

No data there, sorry. You'll want to have a look at current linux kernel
development however. there's some work going on with regard to big RAM -
current limit in production kernel is at or just below 1GB.

> o Is it the general consensus to avoid Transparent proxying if possible, and
> that it is better to force the user to knowingly use the proxy settings in
> their browser?

Yep. TCP-wise you beg for problems if you run transparent proxying. For
example, if you try transparent proxying the usual way (policy route on
your router of port 80 requests to your proxy ) you have to be aware that
your proxy won't get any ICMP packets sent by anything on the route to the
client - those'll go to the original server. Thus MTU Path discovery won't
work, you'd have to disable it in the kernel. There's some other problems
which will cause reset tcp connections to your clients, check for Henriks
mail on the list for further explanations.

Besides, you'll get better efficiency with blocking of port 80 + "real"
proxying: you get to cache ftp requests and web access on ports != 80 as well.

Bye, Martin
--------------------------------------------------
 Martin Bene vox: +43-664-3251047
 simon media fax: +43-316-813824-6
 Andreas-Hofer-Platz 9 e-mail: mb@sime.com
 8010 Graz, Austria
--------------------------------------------------
finger mb@mail.sime.com for PGP public key
Received on Thu Dec 31 1998 - 02:22:11 MST