La question php thread safe or not mérite une réponse nuancée, parce que PHP peut être compilé et déployé dans des modes très différents selon le serveur, les extensions et le type d’application. Ici, je vais surtout clarifier ce que signifient ZTS et NTS, comment vérifier votre installation, dans quels cas le mode thread-safe a du sens, et quels pièges évitent le plus souvent les erreurs de déploiement.
Les points à retenir avant de choisir une build PHP
- ZTS signifie que PHP a été compilé avec Zend Thread Safety, utile quand plusieurs threads partagent le même processus.
- NTS est le choix le plus courant pour PHP-FPM et les architectures web classiques où l’isolation se fait par processus.
- Le bon choix dépend moins de la “version de PHP” que du SAPI, du serveur et des extensions chargées.
- La manière la plus fiable de vérifier votre cas est de tester
PHP_ZTSou l’affichage dephp -i. - Les extensions et les binaires doivent correspondre exactement au même mode TS/NTS, sinon le chargement échoue.
- Pour le parallélisme en CLI,
parallelexige un build ZTS, alors quepthreadsest une voie ancienne et limitée.
Ce que signifie vraiment la thread safety en PHP
En pratique, être “thread-safe” ne veut pas dire qu’un langage devient automatiquement sûr dans tous les cas. Pour PHP, cela décrit surtout la façon dont le moteur Zend protège son état interne quand plusieurs threads partagent le même processus. ZTS active cette couche de sécurité, alors que NTS s’appuie sur un modèle où l’isolation vient plutôt des processus ou du serveur web lui-même.
Je fais souvent une distinction simple: la thread safety du runtime n’est pas la même chose que la thread safety de votre code applicatif. Un script peut tourner sur un build ZTS et malgré tout manipuler de façon risquée des fichiers, des sessions, du cache ou des ressources partagées. À l’inverse, un build NTS peut être parfaitement adapté à une architecture web moderne si chaque requête est déjà isolée par un processus de travail.
- ZTS protège l’exécution quand plusieurs threads cohabitent dans le même processus.
- NTS simplifie le moteur quand l’isolation est assurée ailleurs, souvent par PHP-FPM ou par un modèle multi-processus.
- Le mot “safe” concerne ici le moteur et ses extensions, pas la qualité globale de votre architecture.
Une fois cette base posée, la vraie question devient beaucoup plus concrète: comment savoir quel build vous utilisez réellement sur votre machine ou sur votre serveur.
Comment vérifier votre installation sans vous tromper
La méthode la plus fiable reste de regarder l’indicateur exposé par PHP lui-même. Dans un script, la constante PHP_ZTS renvoie true si votre build est thread-safe et false sinon. En ligne de commande, php -i affiche aussi une ligne dédiée à la thread safety, ce qui évite de se fier au nom du package ou à une supposition approximative.
| Méthode | Ce que je regarde | Ce que cela signifie |
|---|---|---|
PHP_ZTS |
true ou false
|
true = build ZTS, false = build NTS |
php -i |
La ligne “Thread Safety” | Affiche directement si le runtime est activé en mode thread-safe |
phpinfo() |
Version, architecture, thread safety | Très utile avant d’installer une extension ou de comparer deux environnements |
| Nom du binaire ou de la DLL |
TS ou NTS
|
Indique souvent le mode attendu, surtout sur Windows |
Sur Windows, la page officielle de téléchargement PHP propose encore des variantes Thread Safe et Non Thread Safe, et les extensions PECL suivent la même logique. C’est un point que je vérifie toujours, parce qu’un mauvais couple PHP-extension finit presque toujours par un échec au démarrage, pas par un avertissement élégant.
À partir de là, on peut décider dans quels contextes ZTS est utile, et dans quels contextes il n’apporte pas grand-chose.
Quand une build thread-safe est réellement utile
Une build ZTS a du sens dès qu’un même processus PHP peut être appelé par plusieurs threads. C’est le cas de certains montages avec Apache en mode multithread, de quelques intégrations en CLI, ou de projets qui veulent faire du parallélisme de manière explicite dans l’espace utilisateur. La documentation PHP rappelle d’ailleurs que le support ZTS est une option de compilation, pas un réglage qu’on active après coup.
| Contexte | Build conseillé | Pourquoi |
|---|---|---|
| PHP-FPM avec Nginx | NTS | Chaque worker gère son isolation, donc ZTS n’apporte pas d’avantage pratique |
| Apache multithread avec mod_php | ZTS | Le moteur peut être partagé par plusieurs threads dans le même processus |
Parallélisme en CLI avec parallel
|
ZTS | L’extension exige explicitement un build PHP avec Zend Thread Safety |
Ancienne extension pthreads
|
ZTS | Elle repose sur le multithreading, mais elle est aujourd’hui considérée comme obsolète |
Je retiens surtout une règle: ZTS ne devient utile que quand plusieurs threads partagent réellement le même runtime. Si votre serveur distribue déjà le travail par processus, le besoin disparaît presque totalement. C’est précisément pour cela que la plupart des sites PHP n’ont aucune raison de chercher ZTS par défaut.
Pourquoi NTS reste le choix standard pour le web
Dans un site web classique, l’exécution PHP passe le plus souvent par PHP-FPM ou par une architecture similaire où les requêtes sont isolées. Autrement dit, le serveur web et le gestionnaire de processus font déjà le travail de séparation, ce qui rend la couche thread-safe moins utile. Dans ce schéma, NTS est généralement plus simple à maintenir et plus cohérent avec la pile applicative.
La documentation PHP recommande aussi de rester pragmatique avec Apache: si l’on veut un environnement multithread, PHP doit être compilé avec ZTS, mais la configuration par défaut la plus prudente reste souvent une approche orientée processus. Je trouve ce point très révélateur: quand l’écosystème officiel vous pousse à limiter les couches de concurrence, ce n’est pas pour faire joli, c’est parce que les effets de bord apparaissent vite dès qu’une extension sort du cadre.
- Le modèle processus + worker est plus lisible à diagnostiquer.
- Le chargement des extensions est souvent plus simple en NTS.
- On évite une couche de synchronisation inutile lorsque le serveur isole déjà les requêtes.
- Les déploiements sont plus prévisibles, surtout sur des stacks standard LEMP ou LAMP modernes.
Cette logique explique pourquoi je déconseille presque toujours de “prendre ZTS par précaution” pour un site web ordinaire. Le bon réflexe n’est pas de choisir le mode le plus technique sur le papier, mais celui qui correspond exactement au runtime réel de votre application.
Les pièges qui font échouer un déploiement
Les problèmes les plus fréquents ne viennent pas d’un bug mystérieux dans PHP, mais d’un mauvais alignement entre le binaire, l’extension et le serveur. Le cas classique: une extension PECL compilée pour NTS est chargée dans un runtime ZTS, ou l’inverse. Le résultat est souvent brutal: erreur au démarrage, module introuvable ou comportement instable dès la première requête.
| Symptôme | Cause probable | Correctif |
|---|---|---|
| L’extension ne se charge pas | Mauvais couple TS/NTS | Prendre une extension compilée pour le même mode que PHP |
| Erreur de bibliothèque au démarrage | Version PHP ou architecture différente | Vérifier aussi PHP_VERSION et PHP_INT_SIZE
|
parallel refuse de fonctionner |
Build NTS | Passer sur une compilation PHP avec ZTS |
| Une extension ancienne se comporte mal en ZTS | Extension non prévue pour ce mode | Choisir une alternative compatible ou revenir à NTS si le contexte le permet |
Un autre piège, plus discret, consiste à croire que tout ce qui marche en CLI marchera aussi dans un serveur web. Ce n’est pas automatique. Les extensions orientées threads sont souvent pensées pour des scénarios très précis, et la documentation officielle en limite parfois explicitement l’usage au CLI. J’ai vu suffisamment de déploiements casser pour une simple confusion entre environnements de test et environnement de production pour considérer ce point comme non négociable.
Ce que je recommande pour un projet PHP en production
Si je dois résumer la décision en une règle simple, je pars toujours du mode d’exécution réel, pas du mot “thread-safe” sur le packaging. Pour une application web classique en PHP-FPM, mon choix par défaut reste NTS. Pour un contexte qui fait vraiment cohabiter plusieurs threads dans un même processus, ou pour du parallélisme CLI avec parallel, je passe sur ZTS.
- Vérifiez d’abord le SAPI et le serveur, puis seulement le build.
- Alignez strictement PHP, l’architecture système et les extensions.
- N’activez ZTS que si vous avez une raison fonctionnelle, pas par réflexe.
- Testez
PHP_ZTSdans votre CI pour éviter les surprises au déploiement.
Ce que je retiens, au fond, est assez simple: la bonne réponse à la thread safety en PHP n’est pas “oui” ou “non” dans l’absolu, mais “oui, si votre runtime en a besoin”. C’est cette cohérence entre serveur, moteur et extensions qui fait la différence entre une pile stable et un déploiement fragile.
