On Wed, 26 Sep 2001, Chris wrote:
> It seems that flushing the queues are far more expensive than we had hoped,
> and one contributing factor seems to be that for a queue run, with, say,
> ~100k messages in the queue, exim ends up moving onto a new message,
> forking, and exiting after discovering that the retry time is not reached.
Yes, I'm afraid that's correct. It has to route all the addresses in the
message, and then examine the retry times for each of them. With several
addresses (or several hosts), some may have reached their retry time,
and some may not.
I designed Exim for our environment - where over 95% of the messages get
delivered immediately, and a queue of over 1000 is very exceptional. I
never envisaged it being run in situations where there were 100k
messages on the queue!
> Is there any way to have the queue runner process examine the message
> *before* forking a process to deliver it?
No,[*] because it isn't just examining it. It has to route all the
addresses to find out which hosts they are aimed for.
As another posted said, the only way to do this would be to write an
external program, but it would have to do much the same work that Exim
already does, so I don't know how much you would save in practice.
---------
[*] Actually, the queue runner does examine the message a bit when it does
the checks for the -R and -S options, but they are simple checks that
are quickly done.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
