1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

The one most powerful feature in 1.2: Deferred tasks

Discussion in 'General XenForo Discussion and Feedback' started by Rigel Kentaurus, Sep 6, 2013.

  1. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    This feature does not get much publicity (no UI involved), and is only mentioned whenever someone asks about something misbehaving, however ...

    From a developer perspective, this is one of the features that I appreciate most. It is powerful and well implemented. It has simplified my life. Some examples.

    On the addon "install" process, some tasks take a long time. However, they don't need to be done "right now", like for example updating counters. Just add a deferred task. Done. The UI is unlocked, the main thread freed, the task is processed asynchronously.

    Any task that needs a "recalculation" can be deferred. I am using this with the widgets. Some widgets have complicated data that can take as much as 30 seconds to recalculate. Now, I just send it to the background. The result is: The page loads instantly, the task is completed eventually.​

    There is so much architecture goodness in the deferred system. Potentially I can decouple the deferred tasks and have it triggered by a minutely cron job. Or I could have a watch on the table that triggers when there is an update. Or I could transform them to a real messaging protocol that observes the events when they happen. They can be processed by a slave, and I don't need to consume my php-fpm threads. From the scalability perspective, they are awesome.

    They are under-utilized too. A lot that is done right now in the _postSave() and _postSaveAfterTransaction() methods can now be thrown to a deferred thread. Especially things that take a long time, like processing subscriptions (why are alerts sent when I click on "Submit"?), tagging notifications ... they don't need to be inline at all.

    The result is a snappier UI. The AJAX call has a short timeout (15-30 seconds), which means that as soon as I hit "Reply", PHP has that much time to process things, but some things don't need to be processed on the UI thread, they can't just be sent to the "background". The result? A faster experience for users.
    Sidane, Marcus, Adam Howard and 13 others like this.
  2. Daniel Hood

    Daniel Hood Well-Known Member

    I'm working on an add on that is goin to have to run a very long script (depending on board data) on initial install (and again on a cron job every so often). I'm thinking of trying to do this with the defer system instead. Any tips/suggestions on implementing this?
  3. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    Right now, anything that rebuilds counters I pushed to a defered task, no need to run it right away, and "eventually" is fine. Works really way for updates.
    You just create your Defered task that extends the Abstract, and add it through the model

    If you don't specify a time, it will run next. Which is usually next hit on any page by someone.
    Daniel Hood likes this.
  4. Daniel Hood

    Daniel Hood Well-Known Member

    So similar to what someone may use a cron for, if it isn't needed on a strict schedule deferring it for next page hit is a better method?

Share This Page