Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!ncrlnk!ncr-sd!hp-sdd!apollo!apollo.hp.com!pato
From: pato@apollo.HP.COM (Joe Pato)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo SR10 Registry Performance
Message-ID: <46707186.20b6d@apollo.HP.COM>
Date: 25 Oct 89 14:11:00 GMT
References: <127@bnrgate.bnr.ca> <46574bed8.000f088@caen.engin.umich.edu>
Sender: root@apollo.HP.COM
Reply-To: pato@apollo.HP.COM (Joe Pato)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 90


In article <127@bnrgate.bnr.ca>, marmen@is2.bnr.ca (Rob Marmen 1532773) writes:
> Thanks for the reply. There are a couple of more pieces of information
> that are relevant.
> 
> 	1) We are running BETA sr10.2 regitries. This was needed to fix
> 	   a problem with a server responding 20 times to each registry 
> 	   request. The new registries fix that problem. This was quite
> 	   serious because we are 100% ethernet and the network load was
>  	   phenominal. Also, HPApollo are working on an ethernet microcode
> 	   fix to cure a problem with short interpacket spacing.

The multiple replies to a request bug existed in an ALPHA version of the sr10.2
registry server.  You were running this to circumvent other problems in your
network.

> 
> 	2) Our site is 100% BSD unix. This puts an additional load on the 
> 	   servers because the /etc files are now streams to the server.
> 	   It's amazing how many programs look at these files constantly.
> 	   The applications have not been modified to take in to account
> 	   that there are now network accesses instead of disk accesses.
> 

Most Apollo supplied application programs do not scan the /etc/passwd file,
they use the standard UNIX passwd file data accessor functions getpwnam()
and getpwuid().  These operations are implemented as remote calls to the 
registry server and avoid having to transmit the entire passwd file.  Third
party applications should also be modified to use these functions rather
than directly reading the file.

If you have several applications that are scanning the password file
frequently,
you might want to create local copies of the passwd file.  (To do so, you would
move the /etc/passwd object to /etc/passwd.real and copy the /etc/passwd.real
file to /etc/passwd periodically from cron).

At sr10.2 we have modified the /etc/passwd object to cache the passwd file 
locally.  When the object is opened, the type manager determines if the cached
copy is current by contacting the registry server, and if not it will cache a 
new copy.  This has two benefits over sr10 and sr10.1 - 1) the data in
the passwd
file is now current instead of potentially being 2 hours out of date and
2) the data is often retrieved from the local disk rather than across the
network.  The latter is especially true if there are infrequent updates to
the passwd file - relative to the number of times the file is scanned.

> Under sr9.7, we had a ratio of 1 registry for 35 nodes. In addition, the 
> workstations were modified so that the /etc directory was resident on each
> nodes. Otherwise the performance was unacceptable.
> 
> At this point, we are going to experiment with a ratio of 1 server for 20
> workstations. It's just a guess, but we reason that since the unix programs
> are going to constantly look at the /etc files, then the number of servers
> should actually be greater than a sr9 site.
> 
> Any comments?  cheers,  rob...
> 
> PS. Again, thanks for the reply.
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> | Robert Marmen             marmen@bnr.ca  OR             |
> | Bell Northern Research    marmen%bnr.ca@cunyvm.cuny.edu |
> | (613) 763-8244         My opinions are my own, not BNRs |

I firmly believe that 1 registry server for 20 workstations is tremendous
overkill.  In the Apollo corporate internetwork we run 1 server for every 100
workstations.  (And we only run so many servers because our internetwork
stretches over 2 states and we want to have a server in every "important"
network for reliability.  We could get by on many fewer servers.)

Statistics gathered over an average 2 business day period indicate that our
corporate internetwork is handling about 25 registry operations per second. 
Peak access to the registry servers is between 35-40 operations per second. 
Stress tests on servers indicate that a server running on an unloaded 8 Mbyte
DN2500 should be able to handle about 64 operations per second before clients
perceive any real degradation in service.  (This would indicate that a single
dn2500 should be able to service our entire 3500+ node internetwork.  Again, we
would not want to do this for reliability reasons and due to the additional
traffic from remote networks.)

Paul Anderson's observations about the U. Mich. environment seem to be
appropriate here.  He observes that 1 server for every 150 machines seems
adequate, but that you really need 4 servers for the first 150 machines for the
load balancing strategy to work well.

 Joe Pato
 Apollo Computer            A Subsidiary of Hewlett-Packard
 NSFNET: pato@apollo.com    UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato