[75] in Hesiod
How do I use hesiod efficiently?
daemon@ATHENA.MIT.EDU (Bob Manson)
Mon Dec 30 09:45:49 1991
Date: Mon, 30 Dec 91 09:33:19 -0500
From: Bob Manson <manson@magnus.acs.ohio-state.edu>
To: greg@duke.cs.unlv.edu
Cc: rsw@eng.umd.edu, jh@efd.lth.se, hesiod@Athena.MIT.EDU
In-Reply-To: Greg Wohletz's message of Mon, 23 Dec 91 13:21:06 -0800 <9112232126.AA07394@Athena.MIT.EDU>
We attempted in September to use Hesiod (DEC's Ultrix implementation)
for maintaining our user databases. We had at the time 4500 users; our
user base will probably grow to around 10,000 users in the next year.
The major problems with using it were a severe lack of memory--the
name server would use 10 megs of memory, and don't forget that this
doubles or triples when you do a zone xfer, since a process is forked
off for each dump--and the slowness of updates (it would take 10-15
minutes to do a zone dump). I also found that the Ultrix nameserver
was unstable, but this is somewhat understandable when you consider
that it's based on named 4.8...
Clearly Hesiod's current implementation isn't suitable for large user
databases or setups with 3 or 4 machines. I ended up developing a
Kerberos-authenticated system to maintain the databases, that provides
instant updates (transactions are handled on a per-record basis) and
a lot less memory usage. I would encourage the Hesiod developers to
consider the inherent problems in using Hesiod with large databases,
since there aren't any real workarounds with the current system. Per-record
updates are a must when dealing with more than 1000-2000 records.
--
Bob Manson, Academic Computing Services, The Ohio State University
manson@magnus.acs.ohio-state.edu
Clearly I don't speak for ACS nor for the university, nor do they speak for me.
