SELECT COUNT(*) FROM wp_actionscheduler_actions WHERE status = 'pending';
-- 15 482Ce résultat, obtenu en pleine soirée de soldes sur une boutique de prêt-à-porter, a révélé qu’Action Scheduler, la file de tâches planifiées native de WooCommerce, accumulait les actions en attente plus vite qu’il ne pouvait les traiter. Chaque commande déclenchait plusieurs tâches asynchrones — envoi d’e-mail, synchronisation vers l’outil de gestion des stocks, mise à jour du CRM — et l’ensemble avait fini par former un embouteillage de plus de quatre heures de retard.
Pourquoi Action Scheduler a atteint sa limite
Action Scheduler s’appuie sur les tables MySQL de WordPress et sur le mécanisme de tâches planifiées WP-Cron ou une exécution via un déclencheur serveur réel, avec un traitement par lots dont la cadence dépend directement de la capacité de la base de données à absorber les écritures concurrentes. Sur un trafic normal, ce mécanisme suffit largement. Lors d’un pic de commandes concentré sur quelques heures, la table wp_actionscheduler_actions elle-même devient un point de contention : chaque tâche traitée génère une écriture de statut, en concurrence avec les écritures de nouvelles commandes sur les mêmes tables MySQL.
L’architecture Redis en parallèle
La comparaison retenue après l’incident n’oppose pas Redis à Action Scheduler comme un remplacement total, mais comme une complémentarité par type de charge. Action Scheduler reste en place pour les tâches de fond classiques (nettoyage, rapports différés, synchronisations peu fréquentes). Une file Redis dédiée, alimentée directement à la création de commande, prend en charge les tâches critiques et à fort volume — l’envoi d’e-mail transactionnel et la synchronisation stock — via une extension utilisant l’extension PHP predis/predis.
add_action( 'woocommerce_checkout_order_processed', function( $order_id ) {
$redis = new Predis\Client( array( 'host' => '127.0.0.1', 'port' => 6379 ) );
$redis->lpush( 'queue:order_events', wp_json_encode( array(
'order_id' => $order_id,
'type' => 'email_confirmation',
'ts' => time(),
) ) );
} );Un ou plusieurs processus PHP indépendants (des workers lancés en dehors du cycle de requête WordPress classique, via une commande WP-CLI dédiée exécutée en continu) consomment cette file avec brpop, traitant les événements sans jamais solliciter les tables MySQL de wp_actionscheduler_actions, ce qui élimine la contention observée pendant l’incident.
Comparatif des deux approches
| Critère | Action Scheduler | File Redis dédiée |
|---|---|---|
| Infrastructure requise | Aucune, natif WooCommerce | Serveur Redis dédié |
| Débit sous forte charge | Limité par MySQL | Plusieurs milliers d’actions par minute |
| Persistance après redémarrage | Garantie (base MySQL) | Configurable, à sécuriser explicitement |
| Complexité opérationnelle | Faible | Moyenne (supervision des workers) |
Le compromis retenu : coexistence, pas remplacement
Migrer l’intégralité des tâches WooCommerce vers Redis aurait introduit une dépendance opérationnelle supplémentaire pour un bénéfice marginal sur les tâches à faible volume. La règle adoptée : toute tâche déclenchée par une action utilisateur directe (commande, paiement) et sensible au délai passe par Redis ; toute tâche de fond récurrente, planifiée à intervalle régulier, reste sur Action Scheduler.
- File Redis : e-mails transactionnels, synchronisation stock temps réel, notification webhook sortante.
- Action Scheduler : rapports différés, nettoyage de paniers abandonnés, tâches de maintenance planifiée.
- Supervision : alerte automatique si la file Redis dépasse 1 000 éléments en attente, seuil défini après analyse du pic initial.
Conseil maison : ne migrez jamais toutes vos tâches asynchrones vers Redis par réflexe après un incident. Identifiez d’abord précisément quelles tâches ont réellement saturé, et ne déplacez que celles-là — le reste gagne à rester sur l’infrastructure native, plus simple à maintenir.
En résumé
Une file Redis dédiée complète efficacement Action Scheduler lors des pics de commandes, en isolant les tâches critiques et à fort volume d’une contention MySQL partagée avec le reste de l’application. Le paramétrage du serveur de base de données lui-même, qui pourrait aussi absorber une part du problème par un dimensionnement différent, reste un axe distinct non traité dans cette architecture applicative.
