Prev: Mail Delivery Using FILTER in access table
Next: Detecting "telnet"?
From: Florin Andrei on 21 Jun 2010 14:08
On 06/19/2010 05:37 AM, Wietse Venema wrote:
> Stefan Foerster:
>> I don't send any large volumes to Yahoo, but I had to use a dedicated
>> transport which ignored much more errors for a popular German freemail
>> provider. Since you are using rate delays, your concurrency limit will
>> basically be one, and this might very well be related to what you see.
>
> This is a good point.
>
> To compensate for this unwanted side effect of reduced concurrency
> INCREASE the fragile_destination_concurrency_failed_cohort_limit
> to 10-20 or so (or REDUCE fragile_destination_concurrency_negative_feedback
> to 1/10 or 1/20).

What happens if both are used with more moderate values?
E.g., I separated a few big destinations into their own delivery paths
and now this is what I have:

yahoo_destination_concurrency_limit = 4
yahoo_destination_concurrency_failed_cohort_limit = 5
yahoo_destination_rate_delay = 1s
yahoo_destination_concurrency_positive_feedback = 1/3
yahoo_destination_concurrency_negative_feedback = 1/8

I'll have another batch of emails to send pretty soon, I'm still
tweaking parameters until then.

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

From: Victor Duchovni on 21 Jun 2010 14:31
On Mon, Jun 21, 2010 at 11:08:04AM -0700, Florin Andrei wrote:

>> To compensate for this unwanted side effect of reduced concurrency
>> INCREASE the fragile_destination_concurrency_failed_cohort_limit
>> to 10-20 or so (or REDUCE
>> fragile_destination_concurrency_negative_feedback
>> to 1/10 or 1/20).
>
> What happens if both are used with more moderate values?
> E.g., I separated a few big destinations into their own delivery paths and
> now this is what I have:

Negative feedback never decreates the concurrency below 1, so with
a non-zero rate-delay, there is no negative feedback, only dead-site
detection. The feedback tuning is appropriate when the rate delay is zero,
and either the concurrency limit is low, or the destination triggers
bursts of connection failures, delivery timeouts, disconnects, ...

> yahoo_destination_concurrency_limit = 4
> yahoo_destination_concurrency_failed_cohort_limit = 5
> yahoo_destination_rate_delay = 1s
> yahoo_destination_concurrency_positive_feedback = 1/3
> yahoo_destination_concurrency_negative_feedback = 1/8

With a rate delay of 1s, the positive/negative feedback parameters
have no effect. Also the concurrency limit has no effect. Only the
failed_cohort_limit is relevant. If you remove the rate delay, and your
mail stream to Yahoo is not too bursty (not jumbo list mails), then
the feedback controls should suffice to keep mail flowing smoothly. If
you need to spread out bursts from large lists that arrive all at once,
rate delay plus higher cohort limits are the only tools at hand.

--
Viktor.

From: Florin Andrei on 21 Jun 2010 15:21
On 06/21/2010 11:31 AM, Victor Duchovni wrote:
> On Mon, Jun 21, 2010 at 11:08:04AM -0700, Florin Andrei wrote:
>
>> yahoo_destination_concurrency_limit = 4
>> yahoo_destination_concurrency_failed_cohort_limit = 5
>> yahoo_destination_rate_delay = 1s
>> yahoo_destination_concurrency_positive_feedback = 1/3
>> yahoo_destination_concurrency_negative_feedback = 1/8
>
> With a rate delay of 1s, the positive/negative feedback parameters
> have no effect. Also the concurrency limit has no effect. Only the
> failed_cohort_limit is relevant. If you remove the rate delay, and your
> mail stream to Yahoo is not too bursty (not jumbo list mails), then
> the feedback controls should suffice to keep mail flowing smoothly. If
> you need to spread out bursts from large lists that arrive all at once,
> rate delay plus higher cohort limits are the only tools at hand.

My email is very "bursty" - event updates and changes sent to many /
most / all subscribers. So then I should do this, I guess:

yahoo_destination_concurrency_failed_cohort_limit = 20
yahoo_destination_rate_delay = 1s

I think that's exactly what you are suggesting. Hopefully Yahoo doesn't
get annoyed by the high cohort limit, but we'll see.

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. :)

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

From: Victor Duchovni on 21 Jun 2010 15:42
On Mon, Jun 21, 2010 at 12:21:45PM -0700, Florin Andrei wrote:

> My email is very "bursty" - event updates and changes sent to many / most /
> all subscribers. So then I should do this, I guess:
>
> yahoo_destination_concurrency_failed_cohort_limit = 20
> yahoo_destination_rate_delay = 1s
>
> I think that's exactly what you are suggesting. Hopefully Yahoo doesn't get
> annoyed by the high cohort limit, but we'll see.

Yahoo won't notice your "cohort limit". You may not need 20, if deliveries
always fail even 20 won't help. The idea is to ride out a short burst
of errors, when *some* deliveries are still succeeding. The size of
the longest error burst that does not indicate that further attempts
are futile is situation dependent, at a fixed non-zero success rate,
increases much beyond the typical burst size have no value (geometrically
decreasing gain after the odds of 1+ successes in N deliveries start to
dominate the odds of no successes).

> 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).

--
Viktor.

From: Wietse Venema on 21 Jun 2010 17:04
Florin Andrei:
> 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. :)

This takes some courage:
http://www.postfix.org/SCHEDULER_README.html

The concurrency of 1 is not documented, but it is the only practical
way to implement this. A rate delay of 1s doesn't have much effect
when you delay on one connection while 99 other connections are in
the middle delivering an email message to the same site.

Wietse

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