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.
