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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
