[OpenAFS] Extremely poor write performance.
Thu, 16 Jan 2003 20:22:43 +0000
Martin Schulz wrote:
>Paul Blackburn <firstname.lastname@example.org> writes:
>>It seems that you looked at the performance of 1 client with 1 server?
>>Are your figures for a single access to a server?
>That is the natural measuring a user would do. That is what is
>important to *him*. That is what *he* will judge AFS on.
>He will more often than not write to a single volume
>and the writes seem to be a problem, as the subject suggests.
Clearly, Robin has found some performance he doesn't like.
It is good to discuss and find ways to improve this.
My point was that there is a bigger picture to consider
and that his test seems to biased against AFS's caching benefit.
A question to ask yourself is how much data reading versus how much
data writing are you likely to do in your day-to-day work on a client
I would suggest that you do more reading than writing.
Go look at the figures in "ifconfig" on a few client systems to see what
I would suggest that it is rarely the case that you have a
What would definitely be more interesting is the situation where
10, 20, 40, 80 clients are accessing a single server.
The previous studies of this suggest that AFS servers handle
increasing numbers of clients load better than NFS servers.
If I am using client number 90 of 90 clients accessing one server
then I would definitely be interested to know if the AFS server
is better able to handle my access requests than an NFS server.
Also, it is not enought to bump up the number of clients,
you also have to do repeat access to the same data for
the benefits of the AFS cache to show. This is likely
to be most apparent for read access.
I would like to see how the Andrew Benchmark runs on
today's hardware/software compared to the results we
saw from a few years ago.
Yes, you are correct, there is all sorts of tuning you could
do to tweak up the performance. For example, using
AFS RAM cache instead of disk cache would signifigantly
improve the stats.
There are other factors which are difficult to include
but give AFS the edge over NFS. For example, if your AFS
cell has 3 (or more) dedicated AFS database servers then
you have distributed the processing load from all clients
across those database servers. This is better than having
a single database server (and also more reliable).