[Mailman-Users] stats

[J C Lawrence]

On 05 Nov 2002 20:00:26 -0500 
Jon Carnes <jonc at nc.rr.com> wrote:

> I was looking at the current number of qfiles and the oldest queued up
> files as a start. Give a list of messages/list currently being worked
> on and the times the messages arrived for processing. Also a list of
> all current qrunner's and how long each has been running.

Assuming a reasonably sized machine (not big), and a list of say 5,000
members with a RCPT TO bundling of say 5, a single post will drain to a
reasonably setup (local DNS, no verify, etc) MTA in under a minute.
Throw 20 posts into the moderation queue and approve them all at once,
then that means what, 4,000 spool entries and a to MTA drain time of
well under 5 minutes.

Its hard to get interested in those sorts of numbers.

What qfiles can and does fill up with however is bounces.  But they're
separately queued in 2.1, so that interest quickly wanes.

So what do we have left: MTA performance.  How well, quickly, etc does
the MTA drain its queues?  It might be nice to correlate that with
individual message broadcasts, but without cross correlation between the
Mailman logs (for Message IDs) and the MTA logs that gets pretty rough.
Further, the only cases in which its actually interesting are those
cases where you have gross volumes of data -- which are also the cases
where the cross referencing is most expensive.

So we'll drop correlated tracking.

Which leaves us simple MTA performance and behaviour.  But then Cricket,
EximStats, Mailgraph and the like handle that space rather nicely.

So what precisely are we trying to do again?

> Then looking at the logs to get a graph of how quickly a list normally
> sends (based on the log entries), both by percent and by pure numbers.

Average drain time is not a constant, or even a reasonable average for
anything but the (boring) quiescent case.  Its a function of system load
due to other activities, number of messages currently trying to be sent
to the MTA (say other approvals), and rate of inbound MTA transactions
-- all of which variables are outside of your control, and in two of the
cases, largely outside of your detection.

> Since I'm looking at the logs I thought of looking at some other
> "tuning stats" to try and give config recommendations to users...
> Though that would definitely be functionality for a second version of
> the script.

> ... But if you think its all useless info, JC, I'll just stop now :-)

Far be it from me to scare you off.  I've been wrong before and I don't
doubt I'll be wrong again.  But, I will try and indicate a few of the
salient features of the landscape to intrepid adventurers.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.