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

On Tue, 13 Jul 1999, Steve Willer 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.

I would second that. My results from a time back indicated (though not
comparable to my other tests) that, yes, RAM disk increased performance,
but no, it was way below of what I would expect a RAM disk being capable
of.

]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?

How about patching (very quick and abyssmal dirty) src/access_log.c, and
put an "#if 0 ... #endif" pair around the body of accessLogSquid() and
accessLogCommon() (inside the braces), if you want to save a few cycles.
Not that I would believe it to be any of the real bottlenecks, though...

Le deagh dhùrachd,
Dipl.-Ing. Jens-S. Vöckler (voeckler@rvs.uni-hannover.de)
Institute for Computer Networks and Distributed Systems
University of Hanover, Germany; +49 511 762 4726
Received on Wed Jul 14 1999 - 01:38:00 MDT