Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!pyramid!decwrl!glacier!reid
From: reid@glacier.ARPA (Brian Reid)
Newsgroups: net.news.adm,net.news.b
Subject: Re: curious 2.10.3 efficiency situation
Message-ID: <5128@glacier.ARPA>
Date: Sun, 9-Mar-86 03:37:51 EST
Article-I.D.: glacier.5128
Posted: Sun Mar  9 03:37:51 1986
Date-Received: Wed, 12-Mar-86 01:45:03 EST
References: <5044@glacier.ARPA> <5104@glacier.ARPA> <10428@amdcad.UUCP>
Reply-To: reid@glacier.UUCP (Brian Reid)
Organization: Stanford University, Computer Systems Lab
Lines: 30
Xref: watmath net.news.adm:552 net.news.b:1311


Grumble. Don't tell me that this didn't happen. It did.

It is absolutely true that the time to process one news article increased
substantially while the torrent was arriving. Or, more precisely, the number
of articles per minute that the machine could process was decreasing. In
particular, the time to process one message became longer than the expected
interval between arrivals of messages, with the result that the queues were
increasing in length. The particular queue that was increasing in length was
the /usr/spool/uucp/X. queue.

Although I spent my energy on trying to fix this problem rather than trying
to diagnose it, I did make a few measurements and form a few theories.

I believe that the extra time to process articles was caused by some
combination of these two factors:
   (1) The huge /usr/spool/uucp/X. directory (200+ entries at the beginning;
	900+ entries before I took drastic action. I believe that this 
	slowed uuxqt down considerably.
   (2) The huge history file. At the moment my /usr/lib/news/history
	file is 1.2 megabytes, and has 17000 messages in it. This is about
	double what it usually runs. I believe that inews is running a bit
	slower when the history file gets this big (it still has to search
	to resolve hash conflicts).

Unfortunately, I forgot to turn on system accounting before all of this, so
I don't have any hard data about how well it was working. 
-- 
	Brian Reid	decwrl!glacier!reid
	Stanford	reid@SU-Glacier.ARPA