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

On Tue, 13 Jul 1999, Scott Hess wrote:

> At worst, put the cache on a ramdisk...

Well, it's an interesting idea, but currently the kernel is my bottleneck.
Not the disk. Putting the files in ramdisk still involves system calls,
path parsing, etc. It would probably be a bit better, but I was really
hoping for a way to avoid system calls entirely in this case.

Small rant: I've been a bit frustrated over the apparently inflexibility
in some portions of Squid. Why is it that we _must_ have an access_log,
for example? I could write to /dev/null, but Squid is still going to build
the log line in its buffer and make the kernel calls to output to the log.
Also, why is it necessary that I have an on-disk cache? Surely there are
others who are caching very small amounts of data but for whom performance
is critical...what about us?

> but that should be easy enough to work into the startup script. If you're
> lucky, your OS will even be able to directly suck data from the ramdisk
> blocks to wherever it belongs, so you don't end up with duplicate in-memory
> copies (one in ramdisk, one in fs buffers, one in squid :-).]

That's true, although truthfully that machine is swimming in RAM. It has
512MB RAM, and it's basically just running Squid. I have Squid configured
for something small (either 256MB or 128MB, can't remember), and the rest
is just going to the kernel.
Received on Tue Jul 13 1999 - 10:48:57 MDT