From owner-freebsd-current Fri Sep 17 16:15:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id E606115AF3 for ; Fri, 17 Sep 1999 16:15:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04201 for ; Fri, 17 Sep 1999 16:12:31 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA54721; Fri, 17 Sep 1999 11:56:36 -0700 (PDT) (envelope-from dillon) Date: Fri, 17 Sep 1999 11:56:36 -0700 (PDT) From: Matthew Dillon Message-Id: <199909171856.LAA54721@apollo.backplane.com> To: Brad Knowles , current@FreeBSD.ORG Subject: Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...) References: <199909171658.JAA53751@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message