Article 53842 of comp.unix.solaris: Path: mri.com!newsfeed1.aimnet.com!fsc.fujitsu.com!agate!nntpfeed.doc.ic.ac.uk!sunsite.doc.ic.ac.uk!warwick!lyra.csx.cam.ac.uk!webadm From: webadm@info.cam.ac.uk (WWW server manager) Newsgroups: comp.unix.solaris,comp.infosystems.www.servers.unix Subject: Re: Why is the Solaris doors mechanism so slow? Date: 21 Jan 1997 23:24:22 GMT Organization: Computing Service, Cambridge University, England Lines: 36 Distribution: inet Message-ID: <5c3j76$f5f@lyra.csx.cam.ac.uk> References: <5c0nj3$1ig@isolar.Tujunga.CA.US> <5c2ssv$d5g$1@newsy.ifm.liu.se> NNTP-Posting-Host: cygnus.csi.cam.ac.uk Keywords: Solaris 2.5 doors nscd DNS nss_dns.so.1 libresolv Xref: mri.com comp.unix.solaris:53842 comp.infosystems.www.servers.unix:10602 In article , Thomas M. Maslen wrote: > On machines where more than one process will make a habit of doing > DNS lookups, see whether "nscd -e hosts,no" helps at all. I'm fairly sure I've seen recommendations from Sun that systems making serious use of DNS lookups, in particular any sort of network server, should have DNS access through nscd disabled, because of the performance issues with the current implementation. Another problem I've seen (in Solaris 2.5, don't know about 2.5.1) is that nscd seems (i.e. based on observed behaviour, not documented anywhere that I've seen) to (a) totally ignores TTL information from the DNS and (b) cache only one address for systems with multiple A records. This came to light on our web cache, where these points meant that the round-robin ordering of multiple A records (pointing to multiple systems, not multiple interfaces on one system) was totally lost, and when (as was common at the time) the DNS was frequently updated to reflect which systems in the parent cache pool were down (with 5 minute TTL for the DNS entry), nscd would return stale data for up to an hour by default, and minimum ten minutes. If the single cached address was for a newly-down system, that was especially bad, as our cache wouldn't automatically bypass a dead parent cache. :-) [It didn't help load-balancing much, either.] Having a local, automatic DNS cache is an attractive idea until you find that it can only handle one request at a time, blocking others if there's a delay in getting a response, and that it totally masks important features (TTL, round-robin shuffling of multiple addresses) of the DNS that many sites rely on! I'd therefore advise disabling nscd caching of DNS data on systems where these issues may be a problem, unless/until nscd handles the situation better. John Line -- University of Cambridge WWW manager account (usually John Line) Send general WWW-related enquiries to webmaster@ucs.cam.ac.uk