Graeme Fowler wrote:
> On Thu, 2011-01-27 at 11:31 -0500, Sergei Gerasenko wrote:
>> Sorry about not replying to the list. Thank you for the tips. I already took
>> out the queue running out of my webapp and changed the time downt to 3
>> minutes. Why qq5m and not just q5m?
>
> See http://exim.org/exim-html-current/doc/html/spec_html/ch05.html
>
> In a nutshell, for a large queue
..and ONLY for a large queue... [1]
> you should see an improvement in
> delivering multiple messages to individual domains as the second stage
> queue runner tries to deliver as many as possible down a single
> connection.
>
> Graeme
>
>
suggest 'might' not 'should'.
Whyso?
.. 'as many as possible' may hit the wall at ONE for (at least) two reasons [2]
NOTES:
[1] There can be twice as many of THESE queue runs [3], 24 X 7 x 365, the prep
that gathers info, plus the actually delivery. Even if there is only one message
on the queue. Or ZERO. Not to forget - these are 'interval commanded' queue runs
- not those triggered by actual traffic.
[2] As above, there may only BE one. And/or - some target MTA may limit incoming
to one recipient at a time so as to be able to apply DATA phase per-recipient rules.
[3] One presumes OTHER queue run invocations may have already handled the work
available. Ergo net effect shouod be expected to be variable, need to be
measured by inspection, and even so - not certaqin of repeatability.
Bottom line?
'qq' is a specialty setting that very likely has the chance of 'payback' only on
servers that are heavily loaded, severely bandwidth challenged, hampered by
unreliable DNS returns - or some combination of at least two of those. If then...
Most things already amke extensive use of hints and caching...
Bill
