[2168] in Release_7.7_team
AFS performance measurements
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Mar 15 15:13:03 2000
Date: Wed, 15 Mar 2000 15:07:38 -0500 (EST)
Message-Id: <200003152007.PAA26371@small-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@mit.edu
So, I just did some interesting timings. I used the following 13.7MB
AFS file for my tests:
-rwxr-xr-x 1 7919 mit 14395996 Aug 19 1999 /afs/athena.mit.edu/software/infoagents/arch/sun4x_56/MIT-only/netscape-4.61/netscape
My test was to run:
time tcsh -fc 'repeat 20 cat <filename> | cat > /dev/null'
twice, and take the second result. The extra pipe is to defeat an
optimization in Solaris which makes "cat filename > /dev/null" do no
work. My timings (all in wall-clock seconds):
AFS Local disk Machine desc
Solaris (defender) 12.85 14.59(*) 333MHz Ultra 10
Solaris (small-gods) 11.78 51.52 333MHz Ultra 10
Solaris (whirlpool) 20.83 10.13 270MHz Ultra 5
Linux (drug-lord) 3.47 3.12 450MHz PII
(*) Varied noticeably; as low as 9.43
All of the machines had 128MB RAM, and an AFS cache significantly
larger than 14MB. And yes, I made sure to use the Solaris netscape
binary to test with even on Linux.
So:
* Local disk is about twice as fast as cached AFS on an Ultra
5.
* Local disk is often slower than cached AFS on an Ultra 10,
but it varies a lot. Something may be odd about small-gods,
though it seems perfectly zippy.
* Local disk and cached AFS are about the same speed on Linux,
and are about three and a half times faster than an Ultra 10
(and six times as fast as an Ultra 5).
Using tcpdump, I verified that small-gods generated no traffic to
retrieve an AFS file from the cache.
