We've just done a small experiment on directory lookup times and
time to serve NFS from a Raid striped Alpha, dedicated to file serving.
The results are rather worrying.
1) time to walk a 1000 element directory on the NFS server: h/w raid.
0.059 sec
2) time to walk the same directory, via NFS, alpha -> alpha, directory
not in either nfsd or client-side cache:
13.0 sec
3) time to walk, after first fetch (presumed cached in local client-side)
0.128 sec
4) time to walk, third machine (also alpha) not in local client-side cache
1.5 sec
5) time to walk after first fetch on same (third) machine.
0.128 sec
We checked this on hosts with and without a kernel level patch to enable
a client-side NFS cache option.
This suggests to us that the client-side cached data (in kernel, or in
the client nfsiod daemons) is very effective, but the time to first
fetch is *overwhelmingly* loaded by server-side costs. The differential
between a 13 sec NFS dir and a cached 0.128 dir operation is so extreme
its become visible for almost any user:
MH routinely processes mail in directories of 1000 or more files
news is routinely walking directories of 1000 or more files
webs are (regrettably) often flat spaces of .html files
per-file logging generates thousands of files
source can be hundreds of files per directory (walked into X11 lately?)
We're wondering if there is some simple tuning function we've missed on, or
a well known problem in DU 4.0B which accounts for poor performance for the
initial fetch of data.
Any clues?
cheers
-George
--
George Michaelson | DSTC Pty Ltd
Email: ggm_at_dstc.edu.au | University of Qld 4072
Phone: +61 7 3365 4310 | Australia
Fax: +61 7 3365 4311 | http://www.dstc.edu.au
Received on Wed Jun 10 1998 - 02:46:03 NZST