Free up memory between batches

[WPprodigy]

In AS, you'll see the the common stop_the_insanity() function in use: https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_WPCLI_QueueRunner.php#L118

I had to do something similar for the migration command to prevent the process from being killed by the server.

I added a call to the function here at the end of the loop: https://github.com/Prospress/action-scheduler-custom-tables/blob/master/src/WP_CLI/Migration_Command.php#L71

/*
 *  Clear all of the caches for memory management.
*/
private function stop_the_insanity() {
	global $wpdb, $wp_object_cache;

	$wpdb->queries = array(); // or define( 'WP_IMPORTING', true );

	if ( ! is_object( $wp_object_cache ) ) {
		return;
	}

	$wp_object_cache->group_ops = array();
	$wp_object_cache->stats = array();
	$wp_object_cache->memcache_debug = array();
	$wp_object_cache->cache = array();

	if ( is_callable( $wp_object_cache, '__remoteset' ) ) {
		$wp_object_cache->__remoteset(); // important
	}
}

Things to consider:

• Since the batch number is flexible, do we want to implement a separate counter so memory isn't flushed too much or too little (every 50 - 100 is common).
• The do-while loop ends when $actions_processed is 0, so technically the memory clear would happen unnecessarily a few times.

[thenbrent]

For posterity, the relevant part of my reply from Slack:

Action Scheduler's WP CLI command already has that: https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_WPCLI_QueueRunner.php#L118

But I guess the migration commands are using something else...

Yeah OK, the migration has it's own command which isn't stopping the insanity: https://github.com/Prospress/action-scheduler-custom-tables/blob/master/src/WP_CLI/Migration_Command.php#L69:L72

Unfortunately, ActionScheduler_WPCLI_QueueRunner::stop_the_insanity() is protected. So we'll likely need to implement a custom method for this.

The only other options would be to have Migration_Command extend ActionScheduler_WPCLI_QueueRunner, which isn't great, or make that method public, then update the dependency to require AS 2.2.0 or similar, also not great. Although I guess ideally, we refactor ActionScheduler_WPCLI_QueueRunner::stop_the_insanity() to make it publicly accessible, then use that when available in Migration_Command.

[rrennick]

I think the way to handle this is after merging the custom tables into action scheduler make a base WP_CLI class that has the stop_the_insanity() so it can be implemented in both commands (plus any commands we might want to add later).