Un événement WP-Cron qui interroge successivement trois services de vérification de sécurité, chacun via une requête HTTP sortante, cumule leurs temps de réponse : trois appels de deux secondes chacun immobilisent le processus PHP pendant six secondes au minimum, quand bien même chaque appel individuel passe le plus clair de son temps à attendre une réponse réseau plutôt qu’à calculer quoi que ce soit.
L’architecture séquentielle habituelle
racine-projet/
├── inc/
│ └── securite/
│ ├── class-orchestrateur-scans.php
│ ├── class-scanner-checksums.php
│ ├── class-scanner-extensions-vulnerables.php
│ └── class-scanner-integrite-fichiers.php
└── cron/
└── evenement-audit-quotidien.php
Dans cette structure, l’événement cron appelle chaque scanner l’un après l’autre, de façon strictement séquentielle : le scanner de sommes de contrôle attend sa réponse avant que le scanner d’extensions vulnérables ne démarre à son tour. Le temps total d’exécution de l’événement cron correspond à la somme des temps individuels, ce qui augmente le risque que WP-Cron, déclenché à chaque visite du site, dépasse la limite de temps d’exécution PHP configurée sur l’hébergement.
Ce que les Fibers changent dans cette architecture
PHP 8.1 introduit les Fibers, une primitive de bas niveau qui permet à une fonction de suspendre son exécution à un point précis, généralement en attente d’une entrée-sortie comme une requête réseau, pour laisser d’autres Fibers s’exécuter pendant cette attente, avant de reprendre là où elle s’était arrêtée. Contrairement à un vrai parallélisme multi-processus, les Fibers restent mono-processus : le gain vient de l’entrelacement des périodes d’attente, pas d’une exécution simultanée au sens strict.
racine-projet/
├── inc/
│ └── securite/
│ ├── class-orchestrateur-scans-fibers.php
│ ├── class-scanner-checksums.php
│ ├── class-scanner-extensions-vulnerables.php
│ └── class-scanner-integrite-fichiers.php
└── cron/
└── evenement-audit-quotidien.php
function lancer_scan_asynchrone(callable $scanner): \Fiber
{
$fibre = new \Fiber($scanner);
$fibre->start();
return $fibre;
}
function executer_audit_quotidien(array $scanners): array
{
$fibres = [];
foreach ($scanners as $nom => $scanner) {
$fibres[$nom] = lancer_scan_asynchrone($scanner);
}
$resultats = [];
while (count($resultats) < count($fibres)) {
foreach ($fibres as $nom => $fibre) {
if (!isset($resultats[$nom]) && $fibre->isTerminated()) {
$resultats[$nom] = $fibre->getReturn();
}
}
}
return $resultats;
}
Ce squelette simplifié illustre le principe : chaque scanner démarre dans sa propre Fiber, et l’orchestrateur boucle jusqu’à ce que toutes les Fibers soient terminées. Une implémentation réelle s’appuierait sur une bibliothèque de boucle d’événements, comme celle fournie par un client HTTP asynchrone, pour suspendre effectivement chaque Fiber pendant l’attente réseau plutôt que d’attendre activement en boucle.
Ce que cette architecture ne résout pas
Les Fibers ne réduisent en rien le temps de réponse individuel de chaque service interrogé, elles réduisent uniquement le temps total d’attente cumulé quand plusieurs appels indépendants peuvent se chevaucher. Un scanner unique particulièrement lent reste le facteur limitant de l’ensemble de l’événement cron, quelle que soit l’architecture d’orchestration choisie autour de lui.
Points de vigilance pour une implémentation en production
- Prévoir un délai maximal par scanner, indépendamment de l’orchestration par Fibers, pour éviter qu’un service distant qui ne répond jamais bloque l’ensemble de l’événement cron indéfiniment.
- Journaliser l’échec individuel d’un scanner sans faire échouer les autres, chaque Fiber devant gérer sa propre exception sans interrompre la boucle d’orchestration.
- Vérifier que l’hébergement autorise une durée d’exécution PHP suffisante pour l’ensemble de l’événement cron, même réduite par le parallélisme apporté par les Fibers.
En résumé
Les Fibers de PHP 8.1 offrent un moyen bas niveau d’entrelacer plusieurs tâches d’attente réseau au sein d’un même processus PHP, ce qui réduit le temps total d’un événement cron composé de plusieurs vérifications indépendantes. Cette architecture ne remplace ni le choix des scanners eux-mêmes ni la nécessité de borner chaque appel individuel par un délai maximal explicite.
