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