Chuck,
This can be a very difficult question to answer, and I'm not sure from
what you have indicated here that I can be of much help, but we have
done a bit of performance tuning with AFS. First, you need to determine
if you are most interested in read or write performance. I think you
will find that read performance from AFS is always better than NFS, and
gets better if you can predict that your files will be in cache.
With large files, you should probably consider large chunk sizes and
large cache's to improve read performance. We set our chunk sizes to
8MBs which seems best for our type of data, and our cache's are between
2 to 8GBs so we can try to keep the data we need in cache at all times.
My users seem very happy with these settings for their application that
primarily read large files and lots of them.
However, write performance in AFS can be as bad as NFS. It's not all
that bad when you consider that AFS has to write the data twice, but the
end result is that even with large chunks you can only acheive a bit
better than NFS's write performance. However, in AFS 3.4 you can tell
the cache not to wait til the file is written to the server to return
control to the user that is writing the file. We haven't had a chance
to play with this new feature, but hope to see significant write
performance numbers with this!
Obviously you should consider your network speeds! FDDI is a step in
the right direction, but you may want to consider other options to solve
this problem if you need more speed. HIPPI or ATM seem very interesting
options if you have the $'s to play with this technology today. But
this would improve both AFS and NFS performance.
One other option is to look at DFS. DFS allows chunks to be written
back to the server once they hit the cache. So the user is writing to
cache and the cache is writing to the server at the same time. Cray
looked at this and presented their findings at Decorum a year ago. They
had to mod DFS a bit to get their numbers, but they seemed very good (I
think they were also using HIPPI in their benchmarks?).
I'm not sure this has helped much, but these are some of the things we
have done, and thought about. This could go on and on, but for the sake
of space, I think I'll stop. If you have any detailed questions about
our tests with AFS and NFS, please let me know...Mic
Chuck Hastings wrote:
>
> I'm working on some software which runs on a workstation cluster. The way
> we are distributing the work on the cluster, each node needs to do a
> significant amount of I/O. Currently, we have the file system that we
> are working on NFS mounted between the workstations.
>
> Not surprisingly, the I/O performance using NFS is very bad. I am looking
> for alternatives to using NFS. The only commercial alternative I am aware
> of us AFS.
>
> I was wondering if anyone has done some performance studies of large I/O
> over AFS [we are reading and writing files in excess of 8MB]. I know a
> little about AFS, and my gut reaction is that it will be better than NFS,
> but still not fast enough for our high performance application. I suspect,
> therefore, that we will need to develop an in-house solution to this
> performance bottleneck. But I was hoping to get some empirical data to
> back up my gut feeling.
>
> Thanks in advance for any help.
>
> Chuck Hastings
> Pacific Sierra Resarch Corp
