Date: Fri, 17 Sep 1999 09:58:10 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: current@FreeBSD.ORG, Brad Knowles <blk@skynet.be> Subject: 2xPIIIx450 results & NFS results (was More benchmarking stuff...) Message-ID: <199909171658.JAA53751@apollo.backplane.com> References: <XFMail.990917112639.lh@aus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, these are on duel P3 450 boxes running -CURRENT, with the NFS
performance enhancements. Local disk is an 18G seacrate on an LVD/W
scsi bus.
UFS tests: on 1G duel P3-450 machine, 1x18G seagate SCSI-LW bus
NFS tests: 1G duel P3-450 client, 512M duel P3-450 server, 100BaseTX,
nfsd -n 4, nfsiod -n 4.
Heh heh I accidently left my UFS/NFS-client box configured for 32M of
memory and had gotten through the 1000/50000 tests before I realized
it! So I might as well give you the results:
1000/50000 trans read write (client with 32M of ram)
UFS+SOFT 264/s 841K/s 860K/s
NFS 84/s 270K/s 276K/s
1000/50000 trans read write (client with 1G of ram)
UFS+SOFT 1515/s 4.7M/s 4.8M/s
NFS 107/s 344K/s 352K/s
20000/50000 trans read write (client with 1G of ram)
UFS+SOFT 162/s 366K/s 663K/s
NFS 50/s 125K/s 226K/s
Both the client and server systems were 90%+ *IDLE* during all tests.
The network was operating at 1-2 MBytes/sec through the 1000/50000
tests and from 0.6MB to 1.2MB/sec through the 20000/50000 test. This
isn't surprising since the test is performing essentially random
seek I/O's from a single process.
The benchmark has a number of problems. The 'postmark' program
isn't forking at all, so there is a serious bottleneck in the process
itself, especially whenever a read is issued. It doesn't really give
us an accurate representation of a multi-tasking load. Most NFS servers
have a multitasking load so it isn't really a fair test.
The benchmark shows pretty clearly the inefficiency of large UFS
directories. Putting 20000 files in a single directory is not fun,
and it seriously skews the test results considering what the benchmark
is supposed to be testing.
It seems pretty clear to me that this benchmark has been designed
to show-off the netapp in the best possible light and its competitors
in the worst possible light. Well, ok, that may be an overly-harsh
assessment, but it is still true to some degree. The benchmark is
seriously flawed.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909171658.JAA53751>