tweaking FreeBSD for Squid using

[Terry Lambert]

Alain Fauconnet wrote:
> I don't know. Seems that IDE disks evolve too fast  for  me  nowadays.
> That's also why I was writing that I'm  not  even  sure  that  the  old
> stance "don't use IDE for servers" is still valid.
> OOTH,  I've  had  a lot of trouble  with  busy  IDE-based  (ASUS  P4* m/b)
> FreeBSD servers lately (hard hangs, see bug kern/44867).

FWIW: IDE disks do not support disconnected writes, which is a
significant performance bottleneck when you are writing to the
disk; only disconnected reads are supported.

What this means is that, depending on your content, you could
take a big performance hit for anything you write to cache.

It's a pretty common practice these days for active content
to permit itself to be cached, but have a short expiration;
even if that weren't the case, there's plenty of cacheable
content out there (think "pretty much every image").  What's
worse is that this is precisely the larger content, which is
exactly what you would most want to write to disk.

I guess it really depends on why you are proxy-caching the
stuff in the first place.  If it's because you have a lot of
users behind a big pipe, then you are probably going to end
up being I/O bound on the disk.  I definitely agree with you
that you are better off with multiple cache dirs than with
RAID-0... on the other hand, it could be worth it to have
multiple disks, if you are using IDE, since you get one
concurrent outstanding write per IDE disk you add.  To get
8 concurrent writes, you pretty much need 8 disks, and the
only way to get something like that would be an IDE RAID
controller.  Personally, I'd just spring the extra hundred
bucks for the SCSI, though, and get 128 or more concurrent
writes, instead (tagged command queue depth).

-- Terry