On 06/10/2010 05:09 PM, Mike Hutchinson wrote:
yahoo_destination_concurrency_limit = 4
yahoo_destination_rate_delay = 1s
Well, we do that already (concurrency = 2, rate_delay = 2s). It's still
slow. Do you use multiple outbound email gateways?
Maybe I should try to increase our existing parameters, it looks like
we're using half your values.
Looking at the Postfix queue graphs in Munin, one thing I noticed is
that when the scheduled emails go out (it's not a continuous trickle,
it's in batches, that's just how the software works), a fraction, maybe
25%, go into the active queue right away, the rest seem to be dropped
into deferred either immediately or very quickly. Then they stay in
deferred a long time. Then they move to active for a short while, being
delivered at a slow rate, then they fall back into deferred.
So not only is delivery slow, but the messages spend a very long time in
deferred, therefore amplifying the issue. They seem to spend more time
in deferred than in active.
Again, these are 95% @yahoo.com messages which are legitimate, go to
valid addresses, but are just being throttled by Yahoo. By my lights,
these should spend no time in deferred.
yahoo_destination_recipient_limit = 5
We send exactly one message per destination email address, so that
setting would be redundant for us.
These settings can be tweaked depending on what server you're talking to.
However, these values work for us, after having dealt with not getting
10,000 mails out per week.
That's pretty much our order of magnitude.
So, roughly, what's the delivery rate you managed to obtain? How many
messages / second delivered to Yahoo? It seems like our rate is much
lower, for some reason.
P.S.: We're using postfix-2.3.3-2.1.el5_2 that comes with Red Hat 5. I'm
playing with 2.7 packages and I'm contemplating an upgrade. Would there
be any inherent benefits in my case by simply doing the upgrade? I
noticed there are new control parameters such as
destination_concurrency_failed_cohort_limit but I'm not sure how big of
a difference they would make.
--
Florin Andrei
http://florin.myip.org/
