: The program should dynamically mess with all the variables until it
: gets a statistically relevant curve.
Clarification: My definition of 'curve' is actually 'N dimensional
surface' where N is the number of variables... 5 or 6 or so. Don't
ask me how it could be represented! Maybe as a baseline for each
variable and a spread that covers how the baseline changes with other
variables.
-
I ran the 20000/50000 test with postmark set to 100 subdirectories.
I've added it to the end.
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
20000/50000 trans read write (1G ram, 100 subdirectories)
UFS+SOFT 340/s 723K/s 1.31M/s
NFS 43/s 110K/s 199K/s
I also ran the tests on a 2-disk stripe CCD (verses a single disk),
but the results were the same - due to the lack of parallelism I guess
the disk performance is not a big issue.
One thing of interest to note, especially as it relates to the
performance degredation with a larger number of files, is that
'systat -vm 1' reports an approximately 50% name-cache hit no
matter what postmark is doing. In otherwords, postmark is creating
a new file (namecache miss), opening it (namecache hit), doing some
I/O, and then closing it.
In real-life... for example, with a mail or web server, the namecache
tends to be somewhat more effective then 50%. The web servers at BEST
generally had a 95%+ name cache hit rate. The name cache misses are
what are causing the lion's share of the directory inefficiencies.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message