Re: [exim] -qq vs. -q

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Philip Hazel
Dátum:  
Címzett: John Goerzen
CC: exim-users
Tárgy: Re: [exim] -qq vs. -q
On Tue, 9 Nov 2004, John Goerzen wrote:

> My main questions right now revolve around the queue. First off, the
> difference between -q and -qq. According to my reading of the manpage,
> -qq would be quite desirable -- it seems like it would go easier on both
> local and remote resources by establishing a single connection to a
> remote machine for transmitting various different messages that are
> going to it. Yet -qq is not the default. Why is that? It makes me
> think that there is a tradeoff that I'm not understanding. Is there?


-qq is not the default because, in the "standard" configuration, a
delivery is started for each delivery as soon as a message arrives. In
the environment for which I designed Exim, this succeeds about 95% of
the time. For those messages that fail, Exim remembers which host they
are destined for, and does send multiple messages over one connection if
possible, later.

-qq is useful when you have a queue of messages which have NOT been
subjected to an immediate delivery attempt. In this case, Exim does not
know which hosts they are destined for. Typically this is in situations
such as a host that is not always online. The queue accumulates while it
is offline; having connected (dial-up, or whatever), it then makes sense
to do a -qq run.

> Also, from my reading of Exim's queue-management system, it sounds a lot
> like the Sendmail queue manager I remember from my days prior to Postfix
> (say, 5 years ago).


There is no "manager". Exim was designed for environments where >95% of
messages get delivered right away. Queue runners are intended to be
handling only "problem" messages.

> That is, it could get hung up repeatedly on sites that are extremely
> slow or have nonresponsive DNS servers.


That is not entirely true for two reasons:

(1) Each queue runner processes the queue in a random order.

(2) If one queue runner doesn't finish before it is time to start
another, that's not a problem. Another one starts. It will skip the
problem message (because the first queue runner is still handling it).

Sure, there is some delay, but remember we are talking about messages
that didn't get delivered at the first attempt, so they are already
delayed.

> Also, Postfix has a lot of controls regarding backoff,
> ramp up, etc. that seem useful.


See the retry configuration (chapter 32 in the current manual).

In practice, however, I think many people just go with the standard
defaults.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book