On Thu, 13 Jun 2002, Greg Ward wrote:
> The docs for queue_run_in_order say:
>
> Thus, setting queue_run_in_order with split_spool_directory may degrade
> performance when the queue is large.
> * how large is large?
How long is a piece of string? I'm afraid I have no measurements of
this either way. Hence my cautious use of "may".
> the system where I'm considering enabling
> queue_run_in_order typically has 1000 .. 2000 messages in
> the queue; I've seen it as low as 600 and as high as 6000
> (when the local DNS cache was on holiday) I assume this is
> *not* a large queue.
To me, who manages hosts where the queue length is usually less than 20,
anything over 1000 seems "large". :-)
> * is the general admonition against queue_run_in_order a result of
> the possible performance degradation? or are there other good
> reasons not to use queue_run_in_order?
Another poster has given the reasons for Exim's default, but it's also
stated in the manual:
Exim processes the waiting messages in an unpredictable order. It isn't
very random, but it is likely to be different each time, which is all
that matters. If one particular message screws up a remote MTA, other
messages to the same MTA have a chance of getting through if they get
tried first.
> I did have queue_run_in_order enabled for a few days back in May, and my
> vague, subjective impression was that new messages tended to sit in the
> queue before any delivery attempts for longer than they had previously.
Yup, that is exactly what I would expect, on a statistical basis. It's
always going to try the new messages last.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
