En bref : le JIT de PHP (compilateur just-in-time) traduit en code machine, pendant l'exécution, le code PHP fréquemment exécuté. Il est arrivé avec PHP 8.0, fait partie d'OPcache et est désactivé par défaut depuis PHP 8.4. Les tâches gourmandes en calcul y gagnent nettement en vitesse, les sites typiques comme WordPress à peine. Le gain le plus important vient d'OPcache, d'une version de PHP à jour et d'une gestion des processus bien réglée, et chaque version à jour apporte en même temps les correctifs de sécurité nécessaires.
Qu'est-ce que le compilateur JIT en PHP ?
PHP est un langage interprété : le code source est d'abord traduit en bytecode, les opcodes, et c'est le Zend Engine qui les exécute. Un JIT va un pas plus loin. Il observe quelles portions de code s'exécutent souvent et traduit précisément celles-ci en code machine pour le processeur. À partir de là, elles s'exécutent sans passer par l'interpréteur.
La RFC d'introduction décrit le JIT comme une partie quasi autonome d'OPcache. Le code machine produit se trouve dans une zone supplémentaire de la mémoire partagée d'OPcache. Avec PHP 8.4, le projet a reconstruit le JIT ; selon la page de publication, la nouvelle implémentation repose sur le framework IR, une représentation intermédiaire commune pour la génération de code. La manière dont le moteur fonctionne en dessous est expliquée dans le Zend Engine.
OPcache d'abord : la véritable base des performances
Sans OPcache, PHP retraduit chaque fichier à chaque requête. OPcache conserve le bytecode en mémoire partagée, de sorte que tous les workers le réutilisent. Pour un site avec système de gestion de contenu, c'est de loin le levier le plus important. Depuis PHP 8.5, OPcache est, selon la RFC adoptée, compilé en dur dans PHP ; les réglages ini connus continuent de déterminer si le cache est actif.
Valeurs par défaut importantes selon le manuel : opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 et opcache.revalidate_freq=2. Avec ce dernier réglage, OPcache vérifie au plus toutes les deux secondes si des fichiers ont changé. Qui désactive validate_timestamps doit vider le cache ou redémarrer PHP après chaque déploiement. Plus de détails sous OPcache expliqué.
Configurer le JIT de PHP : modes et réglages
Le JIT est piloté par deux directives :
| Directive | Défaut à partir de 8.4 | Défaut avant 8.4 | Signification |
|---|---|---|---|
opcache.jit |
disable |
tracing |
mode du JIT |
opcache.jit_buffer_size |
64M |
0 |
mémoire pour le code machine généré, 0 désactive le JIT |
Pour opcache.jit, le manuel connaît ces valeurs : disable (entièrement désactivé, non activable à l'exécution), off (désactivé, mais activable à l'exécution), tracing ou on (recommandé pour la plupart des utilisateurs) et function. Il existe en outre une notation numérique à quatre chiffres pour les réglages fins.
; Activer le JIT de façon ciblée, p. ex. pour des workers gourmands en calcul
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Le statut d'OPcache indique si le JIT tourne :
php -i | grep -i "opcache.jit" # réglages de la CLI
php --ri "Zend OPcache" # configuration de l'extension OPcache
Notez que la ligne de commande peut utiliser d'autres réglages que PHP-FPM. Pour l'exploitation web, ce qui compte est la sortie de phpinfo() dans le contexte FPM, idéalement consultée uniquement en interne puis de nouveau supprimée.
Que apporte le JIT en pratique ?
Les auteurs de la RFC ont mesuré : le script synthétique bench.php s'est exécuté plus de deux fois plus vite avec le JIT. Avec des applications réelles, le gain a été faible ; WordPress est passé à 326 requêtes par seconde au lieu de 315, l'analyseur de PHP s'est exécuté environ 1,3 fois plus vite. La RFC dit ouvertement que le JIT n'accélère pas nettement des applications réelles comme WordPress.
La raison tient au profil des applications web typiques. Elles passent la majeure partie du temps à attendre la base de données, le système de fichiers ou des services externes. Un chemin de processeur plus rapide y aide peu. En revanche, le traitement d'images en PHP, les calculs mathématiques, les analyseurs ou les workers de longue durée peuvent en profiter.
Des performances sans JIT : les leviers les plus efficaces
Pour les sites d'entreprise et les boutiques, cet ordre est payant :
- Version de PHP à jour : les nouvelles versions apportent des optimisations et surtout des correctifs de sécurité.
- Bien dimensionner OPcache : assez de mémoire et de place pour tous les fichiers de l'application.
- Régler PHP-FPM de façon adaptée : ajuster
pm.max_childrenà la mémoire vive disponible, au lieu de l'augmenter à l'aveugle. - Examiner la base de données : repérer les requêtes lentes, poser des index.
- Mise en cache au niveau de l'application : cache de pages ou d'objets, là où le système le prend en charge.
- Mesurer plutôt que deviner :
request_slowlog_timeoutdans PHP-FPM écrit, pour les requêtes lentes, une trace d'appels dans le slowlog.
JIT, performances et sécurité
Performances et sécurité sont plus étroitement liées qu'il n'y paraît. Premièrement : chaque composant supplémentaire est du code supplémentaire. La RFC d'introduction cite elle-même le risque de bogues dans le JIT, dans la génération de code et l'allocation de registres, ainsi que la difficulté accrue de leur recherche. Qui n'a pas de besoin mesurable du JIT le laisse sur la valeur par défaut disable.
Deuxièmement : OPcache et les workers gardent du code en mémoire. Après une mise à jour de sécurité comme celle de PHP2Shell, les anciens processus continuent de tourner avec l'ancien code jusqu'à leur redémarrage. Vider le cache seul ne remplace pas ce redémarrage, car les failles CVE-2026-109618 et CVE-2026-109619 se trouvent dans le binaire PHP lui-même.
Troisièmement : le meilleur gain de performances, une version à jour, est aussi la mesure de protection la plus importante. PHP 8.2 atteint la fin du support le 31 décembre 2026 ; qui passe maintenant à 8.4 ou 8.5 gagne sur les deux plans. La manière dont nous maintenons les systèmes durablement rapides et durcis est décrite dans le durcissement de serveur pour serveurs web PHP.
Comment PHP SOS aide-t-il concrètement ?
- État des lieux : nous lisons les réglages d'OPcache, du JIT et de FPM et les comparons à la charge et à la mémoire vive.
- Mesurer les goulots d'étranglement : avec le slowlog et les indicateurs du serveur, nous trouvons où le temps se perd réellement.
- Configurer en sécurité : le JIT seulement là où il aide de façon avérée ; OPcache de sorte que les déploiements et mises à jour prennent proprement effet.
- Planifier les mises à jour : changements de version avec test et redémarrage documenté, pour que la vitesse et le niveau de correctifs soient au rendez-vous.
Questions fréquentes
Le JIT est-il actif par défaut dans PHP ?
Plus depuis PHP 8.4 : la valeur par défaut de opcache.jit est disable. Auparavant, tracing était préréglé, mais le tampon opcache.jit_buffer_size était à 0, de sorte que le JIT ne tournait pas non plus.
Le JIT accélère-t-il WordPress ?
Guère. Dès la RFC d'introduction, les auteurs écrivent que le JIT n'accélère pas nettement des applications réelles comme WordPress. Leur valeur mesurée est passée de 315 à 326 requêtes par seconde.
Ai-je besoin d'OPcache si je n'utilise pas le JIT ?
Oui. OPcache stocke le bytecode compilé en mémoire partagée et épargne à chaque requête une nouvelle compilation. C'est, pour presque tout site PHP, le levier de performance le plus important. Depuis PHP 8.5, OPcache est intégré en dur à PHP.
Le JIT est-il un risque de sécurité ?
Plus de code signifie plus d'erreurs possibles. La RFC d'introduction cite elle-même le risque de bogues dans le JIT et la difficulté accrue de leur recherche. Qui n'en a pas besoin le laisse désactivé ; qui l'utilise devrait installer les mises à jour particulièrement vite.