[613] in Info-AFS_Redistribution
NFS vs. AFS builds
daemon@ATHENA.MIT.EDU (John Carr)
Thu Feb 13 23:00:38 1992
To: info-afs@transarc.com
Date: Thu, 13 Feb 92 21:41:53 EST
From: John Carr <jfc@athena.mit.edu>
I just did two tests to compare AFS, UFS, and NFS.
Test 1:
I ran a program that did multiple stats on a Berkeley file system, NFS, and
AFS. The NFS server was 3 hops away (2 ethernets and an FDDI ring).
Times are milliseconds system time (real time) for a call to stat().
UFS NFS AFS
"." .4 .5 1
".cshrc" .6 3 (12) 1
nonexistant 1.5* 2 (12) .8**
* 1.2 for a directory with 31 entries, 2.1 for a directory with 98 entries
** .5 for a directory with 37 entries, 1 for a directory with 600 entries
The system call overhead is about .1 ms.
Test 2:
Time to run "make -n" in the X11R5 Xlib directory. "make depend" has not
been run. In all cases the directory was mostly, but not entirely, up to
date (make printed 4-6 KB output for all the tests, most of which was the ar
command to create libX11.a). My stat cache size is much larger than the
number of files in the Xlib directory.
AFS, directory full of symbolic links to real sources:
/mit/x11/build/rt/lib/X > time make -n > /tmp/makelog
38.2u 129.7s 4:13 66% 11+70k 1+11io 3pf+0w
/mit/x11/build/rt/lib/X > time make -n > /tmp/makelog2
38.1u 111.2s 2:46 89% 11+70k 0+10io 1pf+0w
(the data was not in cache before the first "make")
UFS (files, not links):
/u1/X11R5/lib/X > time make -n > /tmp/makelog3
37.4u 9.8s 0:58 81% 11+68k 35+8io 1pf+0w
NFS (files, not links):
/demi/u2/X11R5/lib/X > time make -n > /tmp/makelog4
39.2u 53.7s 3:44 41% 11+67k 0+10io 1pf+0w
/demi/u2/X11R5/lib/X > time make -n > /tmp/makelog5
38.7u 54.5s 3:34 43% 11+67k 8+10io 1pf+0w
AFS (files, not links):
/mit/x11/src/mit/lib/X > time make -n > /tmp/makelog6
36.8u 103.5s 2:32 91% 11+70k 0+7io 1pf+0w
/mit/x11/src/mit/lib/X > fs flushv .
/mit/x11/src/mit/lib/X > time make -n > /tmp/makelog7
37.6u 111.6s 2:45 90% 11+70k 0+7io 1pf+0w
/mit/x11/src/mit/lib/X > find . -exec fs flush {} \;
22.5u 78.8s 3:24 49% 7+15k 4+941io 3733pf+0w
/mit/x11/src/mit/lib/X > time make -n > /tmp/makelog8
37.2u 111.5s 2:47 88% 11+70k 0+4io 1pf+0w
(I ran this test in our source tree. There are usually no objects,
so I ran 'make -t' first. This would have put everything in cache.)
NFS was faster than AFS only when the data had not been cached. AFS used a
lot more CPU time than either NFS or UFS, even though it took less real time
than NFS once the file stats were cached.
Symbolic links had a much smaller effect than I would have thought. See
below for a reason this may not be true in general.
Summary:
cached system real u+s %cpu
AFS + links 130 sec 253 66
AFS + links X 111 166 89
AFS X 104 152 91
AFS 112 165 90
AFS 112 167 88
UFS 10 58 81
NFS 54 219 42
Machine and OS info:
IBM RT model 125. 16 MB memory. BSD, not AIX.
I've made some changes to my AFS kernel code. The biggest change relative
to the Transarc code is that my AFS cache is in virtual memory; this should
not affect the time for stat() but will help reading and writing. I suspect
this is why symbolic links didn't hurt performance (I have 679 dcache
entries, which is more than the number of symbolic links referenced in this
test). I expect SunOS and AIX 3 will be similar, while Ultrix and other BSD
systems will be slowed much more by large numbers of symbolic links.
I run "afsd -daemons 4 -stat 2000".
NFS is an old version; newer versions have better attribute caching. I run
6 biods.
The NFS server for the X test is a PS/2 model 80 (25 mhz 80386, 16 MB
memory, SCSI disks, 4 nfs daemons). It is on the same ethernet.
The AFS server with the X sources is also on the same ethernet, the
directory /mit/x11/rt/build is on a server two ethernets and an FDDI ring
away. Both servers are VAX 3600s with 16 MB memory, 2 MB buffer cache, and
ra90 disks.
--John Carr (jfc@athena.mit.edu)
