Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!uwm.edu!cs.utexas.edu!howland.erols.net!newsfeed.internetmci.com!news-in2.uu.net!twwells!twwells!not-for-mail From: bill@twwells.com (T. William Wells) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: FreeBSD as news-server?? Date: 16 Oct 1996 14:24:22 -0400 Organization: None, Mt. Laurel, NJ Lines: 40 Message-ID: <54398m$img@twwells.com> References: <537ddl$3cc@amd40.wecs.org> <53u1ic$61i@flash.noc.best.net> <53ucuj$8qh@twwells.com> <540dos$asu@jingoro.prevmed.sunysb.edu> NNTP-Posting-Host: twwells.com In article <540dos$asu@jingoro.prevmed.sunysb.edu>, Chris Fanning <cfanning@jingoro.prevmed.sunysb.edu> wrote: : I'm assuming these numbers are on BSD. FreeBSD2.1.5. : I'm assuming these numbers are on BSD. One thing that I've been wondering : is why I'm getting such slow performance writing articles. A few years ago : I had Linux on this machine and I could get [write] 40 articles/sec. This : is on a 486/66 with 16MB of RAM. And, no, this certainly was not a full : newsfeed! One thing you have to be aware of is that the time to store an article is (now) dominated by the time it takes to search and update a directory. And that's proportional to the size of the directory. What this means is that the time to *store* an article grows faster than the newsfeed size. For a rule of thumb, consider it proportional to the newsfeed size times your spool size. : Doing roughly the same thing today on a P133 with 64MB RAM with FreeBSD I : get a peak of 10 art/sec. (What disks? What disk controller? With disk I/O being the bottleneck, these are critical.) : I was running INN on both machines - 1.4sec I believe. The only behavior : that I know of that's very different between Linux and FreeBSD is that : Linux by default does asynchronous writes when creating directory entries. : Since this is a big part of a newsfeed, has anyone tried turning off the : synced writes on FreeBSD and does it improve performance? mount -u -o async I think will do it; it's in the man page anyway. But I don't know if it makes much difference, though I do run that way. Most of the time is spent in *reading* the directory -- one has to do that in order to determine if the file already exists. Async writes don't help there.