On Fri, 10 Dec 1999 21:44:25 +0000 , James Raftery writes:
> > I think that the "no-trigger" idea has some merit,
> > even for general purpose servers. I will have to
> > try this out myself, but it would seem that reducing
> > SLEEP_TODO in qmail-send.c, and removing the trigger
> > mechanism should eliminate the starvation caused by
> > rapid triggering.
>
> If one considers the wave-like perfermance pattern to be a negative
> thing then this wouldn't really be a solution, as it would make the
> waves even more pronounced.
Well, it depends on (a) your incoming message rate,
and (b) how low you set SLEEP_TODO.
> You would create a pattern of rapid high throughput delivery followed by
> a period of almost total inactivity, and then high throughput SLEEP_TODO
> time later.
> The trigger mechanism may restrict peak performance but it also limits
> wasted time. It tends to smooth the wave pattern out.
However, the point of the post I was responding to
was that the trigger mechanism causes qmail-send to
slow down sending during times of rapid triggering.
By batching the preprocessing, it might be possible
to get an effect like:
while (qmail-send is running)
preprocess a bunch of messages
keep concurrency* maxed out until the next iteration
What I had in mind was setting SLEEP_TODO to a minute
or less. This should give decent response time, with
a *less* pronounced wave-like pattern, assuming that
(a) preprocessing happens much more quickly than sending, and
(b) during each preprocessing run, qmail-send enqueues enough
messages to "keep itself busy" for SLEEP_TODO.
> Perhaps in certain situations a trigger free qmail might be ideal but
> not, IMO, for a run-of-the-mill installation. YMMV, of course.
Yes, if I try this, I'll post results....
--
Chris Mikkelson | ... a pet peeve of mine is people who directly edit
[EMAIL PROTECTED] | the .cf file instead of using the m4 configuration
| files ... I treat the .cf file as a binary file
| - you should too. --- Eric Allman
