On 05 Nov 2002 20:00:26 -0500 Jon Carnes <jonc@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@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.