As several people have requested, here are some benchmarks
comparing AFS and local disk for some of the activities I
spend the most time waiting for.
Workload
cvs co -d g glew-home
(cd g; cvs tag test-perf)
(cd g; cvs tag -d test-perf)
cvs release -d g
All of the above commands were timed;
however, because of bugs with AFS on LINUX,
cvs release -d did not work on AFS LINUX,
and so these times are not reported.
Measurements made on a 550MHz dual processor
Pentium II Xeon, with 512M of RAM.
100MB/s Ethernet; however, I cannot vouch
for the full path to the AFS server.
Disks are 72000 RPM EIDE Ultra DMA II.
All measurements were reported at least 3 times,
typically 5 times; I discard the cold start numbers
(although those matter) and report only a single
typical number - typically the fastest number reported.
I emphasize that this approach favours AFS, since the AFS
numbers improved over time; the local disk numbers
were always fast.
Time
cvs co
AFS: 1:03
local disk: 2.85s
cvs tag
AFS: 1:19
local disk: 1.11s
cvs tag -d
AFS: 1:17
local disk: 1.21s
NOTE: AFS times are in minutes.
Local disk times are in seconds.
I.e. the performance difference here
is more than the 16X that I reported
here, doing compiles, on the UWisc system.
I am somewhat blown away by these time differences.
For comparison, on an older machine (that happens
to be closer to the AFS server)
200MHz IBM AIX RS6000
128MB RAM
time
cvs co
AFS: 1:44
local disk: 1:05
cvs tag
AFS: 2:01
local disk: 1:02
cvs tag -d
AFS: 1:57
local disk: 1:02
This leads me to suspect that the advantage
of local disk over AFS is due to faster local CPUs,
local disks, etc.
On the newer, faster, system - the one where there is
such a huge difference between AFS and local disk
- the config is
-stat 2800
-dcache 2400
-daemons 5
-volume 128
with the file cacheinfo containing the number 150000.
Again, I emphasize that I am *not* the AFS admin;
I am just the user, who likes AFS, and whose budget
paid for the AFS disk space; I didn't set up this
configuration. I am sure that it is sub-optimal.
But that's also part of the problem: sysadmin manpower
to do tuning.
