Xref: utzoo unix-pc.general:5093 comp.sys.att:9092 news.software.b:4434
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!daver!ditka!kls
From: kls@ditka.UUCP (Karl Swartz)
Newsgroups: unix-pc.general,comp.sys.att,news.software.b
Subject: Re: C news on a 3B1/7300 (or B news with mdbm)
Message-ID: <23021@ditka.UUCP>
Date: 25 Mar 90 10:23:22 GMT
References: <22541@ditka.UUCP> <647@magnus.Hotline.Com> <22843@ditka.UUCP> <1990Mar23.182241.24840@eci386.uucp>
Reply-To: kls@ditka.UUCP (Karl Swartz)
Organization: Inaction Central, San Jose, California
Lines: 27

In article <1990Mar23.182241.24840@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes:
>ecicrl (at 3b1) is running B-news 2.11.19 with ... no
>dbm/sdbm/dbz/ndbm/mdbm whatsoever.

>And runs quite happily and swiftly.  Even when catching up on 8 or
>more Mb of news in one continuous UUCP slurp.

Well, ditka was doing ok until I upgraded to a full feed.  Also, as
a belt-and-suspenders kind of guy I have several ihave/sendme feeds.
Those two combined to make performance without db* unacceptable.

I first noticed a serious problem while waiting for a batch to fully
unpack so I could power down without interrupting anything.  After
over 30 minutes working on *one* article (an ihave for 692 article
ids) I gave up.  Later on I clocked a 96 id ihave (which generated
a sendme for 57 of the articles) at 12 minutes, or 8 ids per minutes.

Since switching to dbz I haven't done any timings on these suckers,
but the hourly run of 'rnews -U' finishes before the next one starts,
where before there was a backlog of batches that often approached an
entire day's worth of incoming traffic.

-- 
Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
1-408/223-1308			 |INet	zygot!ditka!kls@apple.com
"I never let my schooling get in |BIX	kswartz
the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148