Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce an API for background processing #336

Closed
ocean90 opened this issue Mar 13, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@ocean90
Copy link
Member

commented Mar 13, 2016

GlotPress has a few task which should run in a background processes. For example the propagation tasks or a possible upgrade routine for #311/#236.

A translator shouldn't have to wait for other tasks which are not his primarily action, which is in general just submitting one translation.

I recently found https://deliciousbrains.com/background-processing-wordpress/ which provides two classes, WP_Async_Request and WP_Background_Process. Something similar would be good base to allow GlotPress (and plugins) to manage processes which are triggered by user interactions but shouldn't block their primarily flow.

Note: WP_Async_Request uses admin-ajax.php, I'd like to try this with a REST API endpoint.

@toolstack

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2016

Looks interesting. Obviously there would be concerns around making sure the background processes don't get stuck.

The REST API seems to be in flux still so I'm not sure that would be a good idea yet.

I wonder how much of this could be accomplished with hooking in to the shutdown action instead so we don't impact the user experience but don't have to build an async system.

@ocean90

This comment has been minimized.

Copy link
Member Author

commented Mar 13, 2016

The REST API seems to be in flux still so I'm not sure that would be a good idea yet.

Not sure why you think that, but the infrastructure is already part of the core. If it's about the endpoints for posts/users/etc, that's not really important for custom routes.

I wonder how much of this could be accomplished with hooking in to the shutdown action instead

Shutdown function are part of the process, so it still blocks further actions/rendering.

<?php
function shutdown() {
    sleep(2);
}
register_shutdown_function( 'shutdown' );

echo "Hi!\n";
$ time php -f shutdown.php
Hi!
php -f shutdown.php  0,01s user 0,01s system 0% cpu 2,027 total
@toolstack

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2016

I haven't been following the REST API too closely, I've just seen some ongoing discussion about how to get it in to core. If that's just the endpoints, then we should be fine to use it.

Yes, but shutdown executes after all html is rendered, so it doesn't block the page display, it just has a longer execution time.

@ocean90

This comment has been minimized.

Copy link
Member Author

commented Mar 13, 2016

it just has a longer execution time.

Which would be bad for XHR requests.

@ocean90 ocean90 added the _performance label Apr 1, 2016

@ocean90 ocean90 modified the milestone: Future Jun 7, 2016

@ocean90

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2016

Closing as maybelater.

@ocean90 ocean90 closed this Sep 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.