Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Sep 1999 21:25:02 +0200
From:      Brad Knowles <blk@skynet.be>
To:        Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject:   Re: 2xPIIIx450 results & NFS results (was More benchmarking  stuff...)
Message-ID:  <v04205547b40842e2de12@[195.238.1.121]>
In-Reply-To: <199909171856.LAA54721@apollo.backplane.com>
References:  <XFMail.990917112639.lh@aus.org> <199909171658.JAA53751@apollo.backplane.com> <v0420553bb40826e849a4@[195.238.1.121]> <199909171856.LAA54721@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 
<http://transit.us-va.remarq.com/feed-size/>), 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, <blk@skynet.be>            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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04205547b40842e2de12>