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.
