Prev: Mail Delivery Using FILTER in access table
Next: Detecting "telnet"?
From: Florin Andrei on 21 Jun 2010 18:10
On 06/21/2010 12:42 PM, Victor Duchovni wrote:
> On Mon, Jun 21, 2010 at 12:21:45PM -0700, Florin Andrei wrote:
>
>> yahoo_destination_concurrency_failed_cohort_limit = 20
>> yahoo_destination_rate_delay = 1s
>>
>> I can't say I understand *why* the 1s rate delay makes the feedback and the
>> concurrency limit parameters irrelevant, so I guess it's time for me to dig
>> deeper into the documentation. :)
>
> With a rate limit, there is no dynamic concurrency tuning. The concurrency
> is always equal to 1 (or zero once the destination is throttled, after
> appropriately many consecutive failures).

Would this analysis be influenced in any way if we take into account the
fact that we deliver exactly 1 message / user address? (no multiple
recipients at all)

--
Florin Andrei
http://florin.myip.org/

From: Wietse Venema on 21 Jun 2010 21:12
Florin Andrei:
> On 06/21/2010 12:42 PM, Victor Duchovni wrote:
> > On Mon, Jun 21, 2010 at 12:21:45PM -0700, Florin Andrei wrote:
> >
> >> yahoo_destination_concurrency_failed_cohort_limit = 20
> >> yahoo_destination_rate_delay = 1s
> >>
> >> I can't say I understand *why* the 1s rate delay makes the feedback and the
> >> concurrency limit parameters irrelevant, so I guess it's time for me to dig
> >> deeper into the documentation. :)
> >
> > With a rate limit, there is no dynamic concurrency tuning. The concurrency
> > is always equal to 1 (or zero once the destination is throttled, after
> > appropriately many consecutive failures).
>
> Would this analysis be influenced in any way if we take into account the
> fact that we deliver exactly 1 message / user address? (no multiple
> recipients at all)

You are asking questions that are answered in the documentation.

http://www.postfix.org/postconf.5.html#default_destination_rate_delay

Please read this text first. Pay particular attention to the
_destination_recipient_limit discussion. Then come back if
the text is not clear, and indicate *what* text is not clear.

Wietse

From: "Mike Hutchinson" on 28 Jun 2010 18:20
> -----Original Message-----
> From: owner-postfix-users(a)postfix.org [mailto:owner-postfix-
> users(a)postfix.org] On Behalf Of Florin Andrei
> Sent: Tuesday, 15 June 2010 6:00 a.m.
> To: postfix-users(a)postfix.org
> Subject: Re: dealing with Yahoo slowness
>
> 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.

[Michael Hutchinson] made a late reply:
Sounds like you've run into the version problem I had some time ago, where
the rate controls were present, but were a bit buggy. See Wietse's post if
you haven't already.

Once we'd performed the upgrade, and applied the rate limiting configuration
everything went smoothly - perhaps try the same values from the original
post and work from there.

Cheers,
Michael.


From: Florin Andrei on 30 Jun 2010 13:15
On 06/28/2010 03:20 PM, Mike Hutchinson wrote:
>
> Once we'd performed the upgrade, and applied the rate limiting configuration
> everything went smoothly - perhaps try the same values from the original
> post and work from there.

More info. This is how the queues always look, it's a very typical batch:

http://i.imgur.com/7MPIx.png

The batch is sent out at midnight (not always at midnight, just in this
case). The active queue is dropping at a pretty good slope - that's
everyone except Yahoo.

Then there's a green bump at 3am and the active queue is loaded with
more mails, but this time it's decreasing more slowly. This is when
basically there's only @yahoo.com email in the queue.

Then it gets thrown in deferred at 4:30am, then briefly in active, then
deferred again, repeat. It's over 99% @yahoo.com at that point.

This is with minimal_backoff_time = 1000 and maximal_backoff_time =
2000. I'll try 500 and 1000 instead, maybe that makes the blue bumps
more narrow.

--
Florin Andrei
http://florin.myip.org/

From: Victor Duchovni on 1 Jul 2010 05:34
On Wed, Jun 30, 2010 at 10:15:10AM -0700, Florin Andrei wrote:

> More info. This is how the queues always look, it's a very typical batch:
>
> http://i.imgur.com/7MPIx.png

This graph has no scale, and would not be very interesting in any case.

Have you made attempt to sign-up for Yahoo's feedback loop, get
whitelisted, etc.?

During each deferred queue run:

- How many messages are delivered by smtp(8)

- How many are deferred by smtp(8) and is the connection dropped
by Yahoo, or are the recipients deferred gracefully?

- Are you subjected to grey-listing? Is your sender address used
to reach a given recipient stable, or does it change with every
mailing?

- How may messages are deferred by qmgr(8), because the transport
is throttled after too many consecutive errors?

- What is your "rate delay"?

- What is your "failure cohort limit"?

For performance tuning you need relevant metrics. In this case you need
to understand the statistics of Yahoo's negative feedback. This said,
the best solution is to work with Yahoo to whitelist you or to stop
sending bulk email to a provider that does not wish to receive your email.

--
Viktor.

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Mail Delivery Using FILTER in access table
Next: Detecting "telnet"?