class Fiber : cette nouvelle classe, introduite dans PHP 8.1 sorti en novembre 2021, permet de suspendre l’exécution d’une portion de code en cours de route et de la reprendre plus tard, sans recourir à des processus ou des threads supplémentaires. Pour un script de supervision qui interroge plusieurs serveurs à la suite, cette capacité change directement la façon dont on peut concevoir une sonde de santé.
Sur un parc de plusieurs serveurs WordPress, un script de supervision écrit de façon séquentielle interroge chaque machine l’une après l’autre, en attendant la réponse complète de chacune avant de passer à la suivante. Si dix serveurs répondent chacun en une seconde, le script total prend dix secondes, même si les serveurs auraient pu répondre simultanément. Les Fibers permettent de changer cette logique sans recourir à des extensions tierces de programmation asynchrone.
Le problème du script de supervision séquentiel
Un script classique de vérification de santé, écrit avec des appels bloquants comme file_get_contents ou curl_exec, attend systématiquement la réponse complète d’un serveur avant d’interroger le suivant :
foreach ($serveurs as $url) {
$reponse = file_get_contents($url . '/healthz');
$resultats[$url] = $reponse;
}
Sur un parc restreint, ce fonctionnement séquentiel reste acceptable. Mais dès qu’un serveur répond lentement, ou qu’il ne répond pas du tout et que le script attend l’expiration du délai avant de continuer, l’ensemble de la supervision se retrouve ralenti par ce seul point, alors même que les autres serveurs auraient pu être interrogés en parallèle sans attendre.
Ce qu’une Fiber permet concrètement
Une Fiber encapsule une portion de code dans un contexte d’exécution que l’on peut suspendre, via l’appel Fiber::suspend(), puis reprendre plus tard via la méthode resume() appelée depuis l’extérieur de la Fiber. Ce mécanisme ne crée ni thread ni processus système : il reste géré à l’intérieur d’un seul processus PHP, ce qui le rend léger comparé à des solutions basées sur des processus multiples.
$fiber = new Fiber(function (string $url): string {
$curl = curl_init($url . '/healthz');
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_TIMEOUT_MS, 2000);
$reponse = curl_exec($curl);
return $reponse;
});
$fiber->start($url);
Orchestrer plusieurs sondes avec curl_multi et les Fibers
Pour paralléliser réellement les vérifications réseau, les Fibers se combinent avec la fonction curl_multi_exec, qui permet de gérer plusieurs connexions réseau simultanées au sein d’une même boucle. Chaque Fiber démarre une requête, se suspend en attendant que curl_multi_exec signale que la réponse est disponible, puis reprend pour traiter le résultat :
$multi = curl_multi_init();
$fibers = [];
foreach ($serveurs as $url) {
$fibers[$url] = new Fiber(function () use ($multi, $url) {
$curl = curl_init($url . '/healthz');
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_multi_add_handle($multi, $curl);
Fiber::suspend();
return curl_multi_getcontent($curl);
});
$fibers[$url]->start();
}
$actifs = null;
do {
curl_multi_exec($multi, $actifs);
} while ($actifs > 0);
foreach ($fibers as $url => $fiber) {
$fiber->resume();
}
Le résultat final se rapproche du temps de réponse du serveur le plus lent du parc, plutôt que de la somme des temps de réponse de tous les serveurs interrogés, un gain net proportionnel à la taille du parc supervisé.
Ce que les Fibers ne remplacent pas
Les Fibers restent un mécanisme bas niveau : elles ne fournissent pas, à elles seules, une boucle d’événements complète ni une bibliothèque de programmation asynchrone prête à l’emploi. Des bibliothèques construites au-dessus des Fibers apportent une abstraction plus confortable pour des cas d’usage complexes, mais pour un script de supervision ciblé, un usage direct combiné à curl_multi reste suffisant et lisible.
- Les Fibers suspendent et reprennent l’exécution sans thread ni processus
- Elles se combinent naturellement avec
curl_multi_execpour du réseau parallèle - Le temps total se rapproche du serveur le plus lent, pas de leur somme
- Elles ne remplacent pas un outil de supervision commercial complet
Sur notre script de supervision interne, le passage aux Fibers a ramené le temps de sonde d’un parc de douze serveurs de plusieurs secondes à moins d’une seconde, sans changer l’architecture générale du script.
Ce que cette approche ne tranche pas
Ce script maison ne remplace pas le choix d’un outil de supervision commercial complet, avec historique, alerting configurable et tableaux de bord, une décision qui dépend de la taille du parc et du budget disponible plutôt que des seules capacités techniques de PHP 8.1.
En résumé
Les Fibers introduites par PHP 8.1 permettent d’écrire un script de supervision qui interroge plusieurs serveurs en parallèle sans recourir à des threads ou processus supplémentaires, en combinant suspension et reprise d’exécution avec curl_multi_exec. Le gain de temps devient significatif dès que le parc supervisé dépasse quelques machines, sans complexifier excessivement le script d’origine.
