Re: slow dnsserver with Solaris 2.5.1

Ernst Heiri wrote:
>
> On Fri, 14 Nov 1997 10:06:02 +0800 (WST) SO Kwok Tsun wrote:
> [snip; about Solaris 2 nscd]
> > You are right. After uncomment this line and restart nscd, it works
> > much better now. Just wonder why nscd affect that much on the
> > performance.
>
> nscd is a bottleneck because it serialises all DNS requests.
> You can analyse the dnsserver process of squid using 'truss'.

Additionally, by default nscd caches successful host lookups for an hour,
regardless of the DNS time-to-live associated with the information, and for a
hostname that translates to multiple addresses it will always return them in
the same order.

You lose the benefit of "round-robin" shuffling of the addresses by your
nameserver (assuming it is a version which would shuffle them) and even if
rapidly-changing DNS data is given a short TTL by its maintainer you may be
stuck with outdated information (e.g. dead system removed) for rather longer
than if the DNS TTL were used properly by the system name-resolving setup.
[I'm not sure if Squid will cycle through multiple addresses itself, but
nscd's fixed response order is certainly a nuisance for other network
applications.]

For example, the TTLs currently set for a selection of popular sites' web
servers are 7200 seconds for www.microsoft.com, 3600 seconds for
www.netscape.com, and 900 seconds for www.yahoo.com. They are clearly aiming
to minimise the effect of a system outage (that needs more than a reboot to
fix it...) by trying to ensure that DNS changes will be seen quickly. With
caching for 3600 seconds by nscd and TTLs such as those just quoted, Squid
will be using stale DNS data for quite a lot of the time.

It should be noted, however, that Squid's default is to cache successful
lookups for 6 hours, unless you override that explicitly or (presumably, not
tried it) you take up the option to use a modified resolver that allows
Squid access to the DNS TTL data. I think Squid's default should be a lot
shorter, but I don't have any idea what would be the best compromise between
noticing DNS changes promptly and minimising the number of lookups!

I've got it set to 5 minutes, but that's partly for historical reasons
dating back to when our pool of parent caches was running non-Squid servers
(so choice of parent was purely round-robin). Their DNS TTL is 5 minutes and
they quite often had to drop dead systems from the DNS during a period when
they were suffering a spate of hardware failures, which I wanted Squid to
notice promptly... 15-30 minutes might be a better compromise for coping
with origin server DNS changes...? Our cache system is running a nameserver,
so frequent lookups to revalidate DNS data should be relatively cheap if
the data has not expired in the nameserver.

                                John Line

-- 
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to webmaster@ucs.cam.ac.uk