Re: [squid-users] squid w/ djbdns : ipcache vs dnscache

On Wed, 2001-09-12 at 17:22, Fabrice Laborie wrote:
> dear all,
>
> It seems that squid is using an internal dns caching facilities,
> that can be configured through ipcache_* parameters.
>
> I am wondering if pple have experience on the impact on
> shrinking ( disable??) the squid built-in ipcache_* to make full use
> of dnscache?

Why? in process lookups are _much_ faster than dns calls which will
always take at least one select loop to process.
 
> in short should we let squid do the proxy business since it is a good
> proxy, and let dnscache do the dns business since it is a good dns cache +
> resolver!

I'd certainly advocate putting djbdns on the LAN somewhere and point
squid at that.

> also, I have a farm of 3 squid servers on a LAN, I guess I might
> want to have 3 dnscache configured as cache+forwarder only
> to a dnscache+resolver ( well actually the resolver could be
> on one of the 3 ). It does make sense not to have each of the 3
> dns try to ask the root servers about cnn.com right ?

You'd probably want two dnscache+resolvers, to provide redundancy, and
if you want to limit root cache lookups you could get the two resolvers
to ask each other. The squid servers I would leave running the internal
ip cache.

> any comment ?? suggestion ??
>
> since we talk about cache, something else is keeping me from sleeping
> at night [;-)]
>
> on my RH7.1 + kern 2.4.10-pre8+reiserfs+ squid 2.4.ST2+diskd + 750MRAM , it
> seems that the OS is caching disk access in memory.
> I believe that squid is also caching in memory HotObjects
> in order to deliver MEM_HIT very quickly...
> again, is it really worth to ask squid to deal with this memory
> caching instead of relying on the OS, and let squid concentrate
> on doing the proxy business??

Uhm, yes. If you hand all the disk caching off to the OS, the OS has no
http metadata to judge the value of disk objects, and their relative
worth for keeping in memory. The result of that is lower cache hit
ratios. Squid in fact would be better off with _no_ OS disk caching at
all.

> on one hand i can userstand that specialized code (for ipcache_* or
> for mem_hit) can do a BETTER job than generic code (dnscache or OS),

Yes.

> but maintaining the code (ex: offering unicode dns ...) is extra work

I don't believe the dns code has been altered in over a year. Thats
hardly a heavy work load. Remember we are not writing generic cache dns
proxy code or generic disk cache code, we are writing task specific code
which is less complex.

> for our squid gurus .... and that the gain is maybe not that important:
> ( gaining 10% on a TCP_HIT -> MEM_HIT is great ... but I'd rather gain
> 10% on my TCP_MISS with an _even_ better performing squid ...;-) )

The problems with squid and performance are related to internal
structures and processing, not so much to the fact or non fact of the
objects being cached. For details have a read of the developers list -
we are cognizant of the performance issues and want to make squid faster
too!.

I do agree that simple code often allows one to see better ways of
optimising things that complex code does, and that those optimisations
can be better than the results of the complex code. In fact I can name
several such things that can be done to squid, as parts of its innards
are rearranged by us.

Rob
Received on Wed Sep 12 2001 - 16:18:07 MDT