> > Here's an abbreviated transcript of the *per group* conversation,
> > ignoring the beginning and ending parts:
> >
> > <- list active newsgroup-name
> > -> 215: list:
> > -> newsgroup-name <high> <low> <flag>
> >
> > This is repeated for each newsgroup in the screen. I suspect it tries
> > to avoid a full 'list active' which can be a long operation on a
> > loaded server.
>
> Ugh. That is rouge behavior.
>
> The list command should NOT be used for obtaining upto-date singular
> group information. The GROUP command is the correct place for that.
>
> nntpcache can locate an individual group data from the sum of
> newsgroups very quickly. It uses a 31337 (prime) entry hash table,
> with binary trees for resolving hash collisions.
>
> RFC977 defines the arguments to list as:
>
> LIST {active,newsgroup,active,times,overview.fmt} [pattern]
>
> Note the optional usage of the pattern keyword. This is typically used for
> examples like:
>
> LIST active alt.*
>
> and not for pulling in information on a specific group in isolation, which is
> what your news-reader appears to be doing. When the pattern argument is
> specified, nntpcache walks the entire group list, pattern matching every
> against every group.
But even if nntpcache has to walk the entire group list, I don't understand
(and I can't reproduce) the behavior that Torbjorn Lindgren is seeing.
What I'm seeing is basically the following:
- When connecting to nntpcached, the active file is fetched from the
upstream server (I only have one) if enough time has passed. This takes a
few seconds, but is not a big deal.
- list active <group> is always instantaneous, I've *never* seen it go to
the upstream server.
So even without the patch, list active <group> is very speedy here.
I'd be happy to give Torbjorn Lindgren temporary access to test my server
:-)
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
