Changes between Version 4 and Version 5 of BluePrint/Messaging/Outbound


Ignore:
Timestamp:
09/21/12 08:37:15 (9 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Messaging/Outbound

    v4 v5  
    1313* Email sending is not a common activity for the site -- sends occur less frequently than the periodic task. In that case, kicking off an immediate run of the entire outbound task is not a significant overhead. If the periodic task is set to run infrequently compared to the frequency of new sends, then an immediate run makes entire sense. If new sends are not frequent, this isn't a lot of overhead.
    1414* However, let's say that the site actively uses messaging -- that it's a common event.
    15   * If new sends are significantly more frequently than the periodic task. Now the async runs will dominate, and the periodic task and the site's chosen periodic rate will be irrelevant. The conditions that cause a message to fail and be retained in the queue for retry are unlikely to clear up in a short time, especially if the periodic time was chosen to be appropriate for retries. There will be a lot of overhead just from the task processing and futile retries.
    16   * If sends are common ''and'' the periodic task is scheduled frequently, there would, in fact, be little benefit from launching the queue processing on each send.
     15  * Say new sends are significantly more frequent than the periodic task. Now the async runs will dominate, and the periodic task and the site's chosen periodic rate will be irrelevant. The conditions that cause a message to fail and be retained in the queue for retry are unlikely to clear up in a short time, especially if the periodic time was chosen to be appropriate for retries. There will be a lot of overhead just from the task processing and futile retries.
     16  * If the periodic task is scheduled frequently, there would, in fact, be little benefit from launching the queue processing on each send.
    1717
    1818(Dominic points out that if each outbound send processes the entire queue including retries, then causing outbound sends could be used as a DoS attack. That works especially "well" if the sends are sure to fail and become retries.)