Re: Can I *not* have an on-disk cache?

Clifton Royston wrote:

> Scott Hess writes:
> > > Or optimize the algorithms for main RAM storage - I admit I'm still
> > > shaken by the revelation that the code for Squid will keep cached in
> > > main RAM is entirely and admittedly sub-optimal. I think that explains
> > > a lot of performance bottlenecks there.
> >
> > What you'd really want in this case is not a RAM-optimized cache, but a
> > RAM-optimized accelerator. Everything I've ever heard or seen on web access
> > patterns is that temporal locality is not nearly good enough to make a
> > RAM-based cache worthwhile, except for very specific access patterns. In a
> > CPU cache, you expect to hit the cache in excess of 90% of the time - with a
> > Squid cache, you're talking more like 30% of the time.
>
> I think this has been the underlying assumption, from the days of very
> limited main RAM, but I'm not sure it really holds any longer. The
> reason is that I've read a number of reports of people getting a
> significant hit rate (claiming up to 40+%) with a couple 100 MB of disk
> devoted to their Squid cache. I've got 512MB RAM in the machine I'm
> testing on, and 256MB is about the smallest RAM size we're likely to
> buy new servers with. If one can get a significant hit rate with 200MB
> disk, one ought to get exactly the same hit rate - but deliver it many
> times faster - with 200+MB RAM.

That depends on your average uptimes. If it stays alive for more than one month
each time (wild guess), apparently your reasoning applies, especially with such a
small cache. Maybe people could theorize a little more on this?