I would argue that if you can't control your operating system, then getting
the last ounce of performance out of Squid probably isn't a big deal. If
someone wants a high-performance Squid box, build them a high-performance
Squid box. If they want to add Squid to the services a particular machine
offers, then you're better off taking a conservative stance on tuning Squid
itself.
I mean, if you don't trust the operating system's filesystem caching
abilities, why would you trust it's abilities to do paging in a sensible
manner?
Later,
scott
----- Original Message -----
From: <patrickg@isyndicate.com>
To: Scott Hess <scott@avantgo.com>
Cc: <squid-users@ircache.net>
Sent: Wednesday, November 10, 1999 5:37 PM
Subject: Re: Process size..
> On Wed, 10 Nov 1999, Scott Hess wrote:
>
> > cache_mem only determines what Squid will try to cache. Most modern
> > operating systems do a reasonable job of caching filesystem blocks,
>
> The problems in the above are the definition of "most" and "reasonable."
> I'm using Squid on differing platforms, which are going to define
> "reasonable" differently. I'd wager that many O/S's don't offer a
> lot in the way of knob-twiddling when it comes to their internal
> file-caching behaviour and algorithms. If they do, it's likely pretty
> deeply buried. I'd prefer not to have to trust the O/S, nor is it likely
> that the O/S is going to be doing exactly what I want w/r/t file-caching.
>
>
>
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
\/\
> Patrick Greenwell
> Earth is a single point of failure.
>
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/
>
>
>
Received on Thu Nov 11 1999 - 10:12:48 MST
This archive was generated by hypermail pre-2.1.9 : Wed Apr 09 2008 - 11:57:32 MDT