[OpenAFS] Performance

[Rubino Geiß]

> My developers complain that code compiles are much much slower in AFS
> than on the local disk, but actual file performance when they aren't 
> compiling is not-so-bad. I imagine this is because of the CPU 
> that AFS 
> takes to get the files, so CPU usage is important here.
>
> Nathan

I guess not. We are a compiler construction lab. I already posted pretty
much about our worries -- here once more: Our users complain about the same.
Normal operation such as TeX, word, playing mp3 etc. is quite fast, but
compiling is 1.5 to 10 time slower as on local disk, while in the same setup
NFS slowdown is < 2 for less used servers and network. 

Here are the some considerations and solution (but none is ideal)
	- AFS outperforms NFS by far if you consider only (multiple) reads
AND multiple clients (high load). In most cases, reading is the most
frequent file operation.
	- Performance on NFS generally degrades faster as on AFS if you put
more load on the server (say: more clients accessing the server).
	- AFS is not designed to be a single user - single server file
system; so we are complaining about the wrong thing -- anyway we can hope
(and write code) for AFS to get better on this issue.
	- If you consider small files and many dirs. Creating and especially
deleting them is the slowest part of all. 5 - 20 times slower than on local
disk and 5 - 10 times slower than NFS. (Measurement taken place on the same
low load server, client)
	- It may get better if you use the inode fs instead of nami, but I
hadn’t had the time to test it, yet.
	- You can work around the performance issue by "ln"ing your build
tree to /tmp/ and have your sources in AFS (that is your .o / .class files
are in local space). 
	= DRAWBACK: Collaboration is impossible. It may require rewriting of
build environment. It is impossible for poolroom workstations. It is
difficult for diskless stations. As well it is lame in my opinion. BUT some
of our users do it that way.

Observation:
	- If you create / delete and write many small files in a flooding
manner to the server, you get 
		- almost NO CPU load on the server as well as the client.
		- almost NO traffic on the Ethernet (at least not as near to
saturation)
		- enabling fs storebehind does not help (it only stores
behind for one file, right?)
	- Suspect: deleting and creating a files is done synchronously to
the server so we are experience 2 x the network latency on each operation?
Is this true? Is there a option the get AFS in a less synchronous mode? E.g.
define some commit interval? (All operation in between 30 sec. go in the
disk cache and are written back as a whole.

I hope this helps the discussion to come to any conclusion?! 

Bye, Ruby