Date: Fri, 17 Sep 1999 11:56:36 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brad Knowles <blk@skynet.be>, current@FreeBSD.ORG Subject: Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...) Message-ID: <199909171856.LAA54721@apollo.backplane.com> References: <XFMail.990917112639.lh@aus.org> <199909171658.JAA53751@apollo.backplane.com> <v0420553bb40826e849a4@[195.238.1.121]>
next in thread | previous in thread | raw e-mail | index | archive | help
: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909171856.LAA54721>