We have a customer that sends out some thousands email customized per
user (so we really get one copy per user). The eMails are injected
in "bulks" of about 100 per SMTP session.
I am using qmail-1.03 with Russells big-todo-patch.
For every message we have an extra delivery to a local user "log" (in ~alias)
~alias/.qmail-log contains a small awk script that prints the topmost
Received: line and the Message-Id: line to stdout (i.e. this appears
in the logfile; we do this for accounting reasons).
I have both concurrencylocal/remote set to 120.
The qmail system used is dedicated to this task, no other customers
use it.
During the "injection" and while there are messages to preproceess
the systems deliveries with about 5-15 deliveries (both, local and
remote).
Today I noticed that when there where no more messages to preprocess
from the injection phase, the number of deliveries "jumped" up to
120 both local and remote. At that time there were about 2700 messages
left in the queue.
But while looking at the logfile I noticed that qmail isn't always
using all slots, it deliveres in "waves" (sorry, I have no better word
for that).
It fills up all 240 delivery slots, is rather fast with the 120 local
deliveries (originating from the extra delivery to "log" user) and stays
at 0-5 local deliveries for a while.
It is a bit slower (of course) with the remote deliveries, comes down to
about 10-20 remote deliveries, at which level it keeps for some time
(also adding new deliveries).
After a while it fills boths channels up again to 120 deliveries and the
cycle starts over.
a) is this "normal" behaviour?
b) why is it that way? wouldn't it be faster if alle the channel slots
would be filled at maximum all the time?
To illustrate the behaviour I put a gnuplot plot at
http://www.lamer.de/maex/creative/software/qmail/deliver-stats.gif
The plot covers about 600 seconds and the data is generated from the
the "status:" lines of the qmail logfile. It starts at the moment the
preprocessing phase is over and ends when all messages have been tried
at least once.
Thanks
\Maex
--
SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses
Research & Development | mailto:[EMAIL PROTECTED] | you funny and you need
Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0 | a mouse to delete files
D-80807 Muenchen | Fax: +49 (89) 32356-299 |
