Xref: utzoo news.software.b:1516 news.software.nntp:58
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!kazoo.cis.ohio-state.edu!bob
From: bob@kazoo.cis.ohio-state.edu (Bob Sutterfield)
Newsgroups: news.software.b,news.software.nntp
Subject: Re: Reading news: NNTP v.s. NFS for access to the database
Message-ID: <19153@tut.cis.ohio-state.edu>
Date: 2 Aug 88 03:43:23 GMT
References: <16342@tut.cis.ohio-state.edu> <4246@pasteur.Berkeley.Edu>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University Dept of Computer & Information Science
Lines: 49

In article <4246@pasteur.Berkeley.Edu> fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes:
>In article <16342@tut.cis.ohio-state.edu> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes:
>>
>>A secondary reason why I personally prefer to use NFS to read news
>>is because it's actually faster than using the NNTP protocol.  I
>>have run a "local" rn and a NNTP rrn side-by-side and rn comes up
>>observably better in user responsiveness and feel.
>
>Bob, can you quantify this? In particular, I'd like to know where
>NNTP is taking the hit in performance.  Context switching? I'd be
>surprised if you found that NNTP had significantly higher overhead
>than NFS for this application.

Unfortunately, no, I can't quantify this, and I have no idea at all
where the hit is in the code - though see below for more specific
external observations.  I'd like to sit down with a profiler, but I
haven't had the chance (can you tell by the lag time on this response
that I've been away doing other things this summer?).

The biggest delay in rrn is when following a subject thread with ^N,
or when building an unread-articles subject list with =.  Kill files
seem to take forever, too.  This implies to me that you win with local
rn (or with rn reading from an NFS-mounted filesystem) because you
needn't ship the whole article across the wire just to peek at the
headers.

If my misunderstanding of rrn's guts is showing, I'll appreciate the
education I'm likely to receive :-)

>Is it just that almost all the netnews readers in existence were
>written (read "optimized") for having filesystem access, rather than
>for network access (and NFS hides the details better?)?

I think so.  The show-me-part-of-an-article functions are where local
filesystem access really shines.  If NNTP reader clients require
entire articles before they can peek at the header, then some smarter
clients are in order.  If local rn required that the entire article be
read via NFS before its headers could be scanned, you'd likely see the
performance balance tipped the other way.

If the header-scanning functions like subject threading and kill files
weren't part of rn, then I wouldn't notice the hit in rrn.  But then,
those niceties are a big reason I use rn.

Again, please correct my likely misunderstandings of reader clients -
but do it gently, please.
-=-
 Bob Sutterfield, Department of Computer and Information Science
 The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob