From owner-freebsd-current Fri Sep 17 12:25:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from out1.mx.skynet.be (out1.mx.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id E4B7514F6E for ; Fri, 17 Sep 1999 12:25:40 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by out1.mx.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id VAB05852; Fri, 17 Sep 1999 21:25:37 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <199909171856.LAA54721@apollo.backplane.com> References: <199909171658.JAA53751@apollo.backplane.com> <199909171856.LAA54721@apollo.backplane.com> Date: Fri, 17 Sep 1999 21:25:02 +0200 To: Matthew Dillon , current@FreeBSD.ORG From: Brad Knowles Subject: Re: 2xPIIIx450 results & NFS results (was More benchmarking stuff...) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:56 AM -0700 1999/9/17, Matthew Dillon wrote: > 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. Note that with a mail server, this is precisely the sort of thing that happens with /var/spool/mqueue. In particular, with sendmail, a qf/df pair of files get created, the message is received, the sender is told "250 Ok", then sendmail goes to deliver the message in the background, which 95-99% of the time happens on the first attempt, and then the qf/df pair of files get deleted. So, again, we see that they've actually done a decent first-pass attempt at simulating the load a mail server would place on the filesystem. All that we need to add now are a few more features. ;-) With a news server using traditional spool, the file would tend to get created, live for a relatively significant period of time (days or even weeks before it gets expired), and only then would it get removed. An absolutely full newsfeed these days is running somewhere around 1.1 million files comprising some 55GB of data (see ), or an average of 52,608.71 bytes per article. A very busy mail server might do a million messages per day (or more), but the average message size would be much closer to 2-5KB. The primary difference between mail and news is that news articles tend to live a lot longer (mail messages might live for months or years in a users mailbox, but that's not /var/spool/mqueue, and has a different pattern of access), and they tend to be a lot larger. However, there are still on the same order of number of articles/messages input per day versus deleted per day (assuming you've got a handle on your spool and it's not growing out of control on you), it just typically takes news servers a few days to delete something once it comes in. Thus, the name cache misses might tend to be lower on news servers, but I wouldn't be too willing to bet on it -- an article that got created seven days ago and not touched since probably won't be in the name cache any more than a file that is just now being created. Of course, once you get into CNFS or timehash sorts of news spool storage mechanisms, you've traded the name cache problem and directory update problems in for an entirely different set of problems, and the filesystem may or may not be particularly good at optimizing them, as softupdates is with lots more smaller individual files. -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message