Comparer en temps réel le tarif de trois transporteurs différents avant d’afficher le meilleur au client semble une fonctionnalité raisonnable pour un tunnel de commande. Le problème apparaît dès qu’on l’implémente naïvement : trois appels séquentiels à trois API de tarification externes, chacun pouvant prendre jusqu’à plusieurs secondes, cumulent leurs délais d’attente au lieu de les chevaucher, et le client patiente sur une page de chargement pendant la somme des trois temps de réponse plutôt que le temps du plus lent d’entre eux.
PHP 8.1, sorti fin novembre 2021, introduit les Fibers, une primitive de bas niveau qui permet de suspendre et reprendre l’exécution d’une portion de code sans recourir à des threads système. Ce billet explique comment cette fonctionnalité permet de paralléliser des appels réseau vers plusieurs API de transporteurs, sans entrer dans le choix des transporteurs eux-mêmes.
Pourquoi PHP bloque naturellement sur les appels réseau
Le modèle d’exécution classique de PHP dans une requête web est synchrone et monofil : chaque appel réseau, via wp_remote_post() par exemple, bloque l’exécution jusqu’à obtenir une réponse avant de passer à l’instruction suivante. Trois appels consécutifs à trois transporteurs différents s’exécutent donc l’un après l’autre, jamais simultanément, dans ce modèle de base.
Ce qu’apporte une Fiber concrètement
Une Fiber encapsule une portion de code qui peut être mise en pause via Fiber::suspend() et reprise plus tard via Fiber::resume(), sans bloquer le reste du programme pendant cette pause. Combinée à un mécanisme non bloquant d’accès au réseau, comme les fonctions curl_multi_* de PHP, une Fiber permet de lancer trois requêtes vers trois API de transporteurs, puis de laisser chacune progresser en arrière-plan pendant qu’on attend leurs réponses, plutôt que de les traiter l’une après l’autre :
function requeteTransporteurEnFiber( string $url, array $donnees ): Fiber {
return new Fiber( function () use ( $url, $donnees ) {
$ch = curl_init( $url );
curl_setopt( $ch, CURLOPT_POSTFIELDS, wp_json_encode( $donnees ) );
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
Fiber::suspend();
$reponse = curl_exec( $ch );
curl_close( $ch );
return json_decode( $reponse, true );
} );
}Orchestrer les trois appels avec curl_multi
La vraie parallélisation vient de curl_multi_init(), qui gère plusieurs poignées cURL simultanément dans une même boucle d’événements. Les Fibers apportent ici la lisibilité : chaque appel transporteur reste écrit comme une fonction linéaire classique, sans callbacks imbriqués, tandis qu’un orchestrateur central gère la boucle d’attente commune :
$multi = curl_multi_init();
$fibers = [];
foreach ( $transporteurs as $transporteur ) {
$fiber = requeteTransporteurEnFiber( $transporteur['url'], $donnees_colis );
$fiber->start();
$fibers[] = $fiber;
}
// boucle d'exécution simplifiée : reprendre chaque fibre une fois sa requête terminée
foreach ( $fibers as $fiber ) {
if ( $fiber->isSuspended() ) {
$fiber->resume();
}
}Ce que les Fibers ne sont pas
- Un mécanisme de vrai parallélisme matériel : PHP reste monofil, les Fibers ne font que réorganiser l’ordre d’exécution coopératif
- Un remplacement direct d’Action Scheduler pour des tâches longues asynchrones traitées en arrière-plan
- Une solution qui dispense de gérer les délais d’attente et les erreurs de chaque API individuellement
Architecture en résumé
Requête client
└── Orchestrateur (curl_multi)
├── Fiber Transporteur A ──▶ API A
├── Fiber Transporteur B ──▶ API B
└── Fiber Transporteur C ──▶ API C
└── Comparaison des tarifs reçus
└── Affichage du meilleur tarif au clientSur ce type d’architecture, notre repère est simple : dès que deux appels réseau indépendants doivent aboutir avant d’afficher une page au client, la parallélisation vaut le coût d’implémentation, même modeste, des Fibers.
Notre verdict
Les Fibers de PHP 8.1 ne simplifient pas magiquement le code réseau, mais elles rendent une architecture parallélisée nettement plus lisible qu’une pile de callbacks imbriqués. Pour un tunnel de commande qui doit interroger plusieurs API de tarification transporteur avant d’afficher un résultat, le gain de temps perçu par le client justifie largement cette complexité additionnelle maîtrisée.
