{"id":16469,"date":"2026-01-02T11:51:38","date_gmt":"2026-01-02T10:51:38","guid":{"rendered":"https:\/\/webhosting.de\/php-opcache-invalidierung-performance-spikes-serverboost\/"},"modified":"2026-01-02T11:51:38","modified_gmt":"2026-01-02T10:51:38","slug":"php-opcache-invalidation-pics-de-performance-acceleration-du-serveur","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/php-opcache-invalidierung-performance-spikes-serverboost\/","title":{"rendered":"Invalidation PHP Opcache : pourquoi elle entra\u00eene des pics de performance"},"content":{"rendered":"<p>L'invalidation de PHP Opcache provoque des pics de performance mesurables, car elle doit rejeter le code compil\u00e9 et le reconstruire sous la charge. Je vais vous montrer pourquoi. <strong>Invalidations<\/strong> Augmenter les temps CPU, comment les configurations renforcent les pics et quelles strat\u00e9gies de d\u00e9ploiement permettent d'\u00e9viter les pics de charge.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Invalidations<\/strong> entra\u00eenent des recompilations co\u00fbteuses et g\u00e9n\u00e8rent des pics<\/li>\n  <li><strong>Contr\u00f4les des horodatages<\/strong> augmenter la production d'\u00e9checs de cache<\/li>\n  <li><strong>Niveau de remplissage du cache<\/strong> et les limites de fichiers d\u00e9terminent le taux de r\u00e9ussite<\/li>\n  <li><strong>Strat\u00e9gies de d\u00e9ploiement<\/strong> influencent le verrouillage et la latence<\/li>\n  <li><strong>Optimisation de l'h\u00e9bergement<\/strong> Stabilise durablement les temps de r\u00e9action<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/php-opcache-serverraum-1842.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment fonctionne OPCache en interne \u2013 et pourquoi l'invalidation co\u00fbte cher<\/h2>\n\n<p>OPcache enregistre le code PHP converti en bytecode dans la m\u00e9moire partag\u00e9e, ce qui \u00e9vite l'analyse et la compilation pour chaque requ\u00eate. D\u00e8s que j'appelle un script via <code>opcache_invalidate()<\/code> marque comme invalide, je force le prochain appel \u00e0 une nouvelle compilation, y compris l'optimisation et l'enregistrement. Cela co\u00fbte <strong>CPU<\/strong> et g\u00e9n\u00e8re des retards courts mais perceptibles lors de l'acc\u00e8s \u00e0 de nombreux fichiers. Si le parall\u00e9lisme augmente, les conflits de verrouillage sur les structures de m\u00e9moire partag\u00e9e et le syst\u00e8me de fichiers augmentent \u00e9galement. Ainsi, une requ\u00eate normalement rapide devient soudainement lente, m\u00eame si le reste du code dans le <strong>Cache<\/strong> est un mensonge.<\/p>\n\n<p>OPcache ne supprime pas imm\u00e9diatement un fichier lors de son invalidation, mais le marque pour renouvellement. Lorsque la requ\u00eate suivante arrive, PHP doit r\u00e9analyser et optimiser les scripts concern\u00e9s. Cela concerne en particulier les piles de frameworks et de CMS comportant de nombreux inclus et autoloads. Plus le nombre de fichiers par page est \u00e9lev\u00e9, plus l'impact d'une erreur sur le temps de r\u00e9ponse global est important. Je planifie donc d\u00e9lib\u00e9r\u00e9ment les invalidations afin de limiter le nombre de recompilations parall\u00e8les et <strong>Pointes<\/strong> lisser.<\/p>\n\n<h2>Pourquoi l'invalidation entra\u00eene des pics de performance<\/h2>\n\n<p>Un acc\u00e8s chaud \u00e0 un bytecode mis en cache est extr\u00eamement bon march\u00e9, tandis qu'une nouvelle compilation est nettement plus co\u00fbteuse. Le passage d'un acc\u00e8s r\u00e9ussi \u00e0 un acc\u00e8s manqu\u00e9 g\u00e9n\u00e8re une perte de performance notable. <strong>Pointe<\/strong>: l'analyse syntaxique, l'optimisation, l'entr\u00e9e dans les structures internes et les verrous potentiels s'additionnent. Si plusieurs fichiers sont invalides en m\u00eame temps, l'effet se multiplie. Sous Trafic, ces t\u00e2ches sont lanc\u00e9es en parall\u00e8le et se font concurrence pour <strong>Ressources<\/strong> et prolongent la dur\u00e9e de service. Cela explique les sch\u00e9mas typiques : 16 requ\u00eates en ~200 ms, puis une en ~1,2 s \u2013 un \u00e9chec classique de l'OPcache d\u00fb \u00e0 une invalidation.<\/p>\n\n<p>V\u00e9rification active de l'horodatage (<code>opcache.validate_timestamps=1<\/code>) peut aggraver le probl\u00e8me. Le cache v\u00e9rifie alors fr\u00e9quemment l'horodatage des fichiers et signale rapidement les modifications, ce qui favorise les compilations inutiles en production. Si je mets en \u0153uvre des d\u00e9ploiements sans r\u00e9initialisation, les anciens et les nouveaux fichiers se m\u00e9langent, ce qui entra\u00eene des erreurs. Si le cache est plein, les dommages s'aggravent car le bytecode est \u00e9galement d\u00e9plac\u00e9. La somme de ces facteurs g\u00e9n\u00e8re des pics de latence courts mais significatifs.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/phpopcachemeeting4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9clencheurs fr\u00e9quents dans la production<\/h2>\n\n<p>Je vois surtout des pics l\u00e0 o\u00f9 la validation des horodatages reste active. <code>opcache.validate_timestamps=1<\/code> s'inscrit dans la logique de d\u00e9veloppement, mais dans les environnements live, cela g\u00e9n\u00e8re des <strong>Ch\u00e8ques<\/strong>. Deuxi\u00e8me classique : un <code>opcache.max_accelerated_files<\/code> dans les grands projets. Les fichiers se supplantent alors mutuellement et imposent des recompilations r\u00e9p\u00e9t\u00e9es. Troisi\u00e8mement : cache commun entre les pools PHP-FPM ou les sites, ce qui fait que les invalidations d'un site affectent l'autre. Quatri\u00e8mement : d\u00e9ploiements sans <code>opcache_reset()<\/code> \u00c9crire de nouveaux chemins atomiques, mais conserver les anciennes entr\u00e9es de fichiers dans le <strong>Cache<\/strong> laisser tel quel.<\/p>\n\n<h2>Identifier les sympt\u00f4mes et les mesurer correctement<\/h2>\n\n<p>Je v\u00e9rifie d'abord le taux de r\u00e9ussite et le nombre de touches occup\u00e9es via <code>opcache_get_status()<\/code>. Un taux de r\u00e9ussite nettement inf\u00e9rieur \u00e0 99 % en production indique des \u00e9checs souvent li\u00e9s \u00e0 des invalidations. Si la charge CPU augmente bri\u00e8vement sans pic de trafic, il convient de v\u00e9rifier le niveau de remplissage du cache et <strong>revalidate<\/strong>-Param\u00e8tres. PHP-Info fournit l'\u00e9tat actif, tandis que les m\u00e9triques c\u00f4t\u00e9 serveur rendent les pics visibles. Une introduction pratique \u00e0 des <a href=\"https:\/\/webhosting.de\/fr\/php-opcache-configuration-optimisation-des-performances-cacheboost\/\">Param\u00e8tres OPcache<\/a> aide \u00e0 donner la bonne signification aux valeurs mesur\u00e9es.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/php-opcache-performance-peak-6472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimisation de l'h\u00e9bergement : param\u00e8tres OPcache utiles<\/h2>\n\n<p>Avec quelques param\u00e8tres, j'\u00e9vite de nombreux pics et maintiens une latence stable. En production, je d\u00e9sactive les v\u00e9rifications d'horodatage et contr\u00f4le activement les invalidations via les d\u00e9ploiements. Une m\u00e9moire partag\u00e9e suffisante et un nombre suffisant d'emplacements pour les fichiers sont indispensables pour \u00e9viter que le bytecode ne soit supplant\u00e9. Pour les frameworks comportant de nombreuses cha\u00eenes de caract\u00e8res, je pr\u00e9vois une m\u00e9moire tampon g\u00e9n\u00e9reuse. Le tableau suivant classe les <strong>Param\u00e8tres<\/strong> un :<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tres<\/th>\n      <th>Recommandation<\/th>\n      <th>Effet<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>opcache.enable<\/code><\/td>\n      <td>1<\/td>\n      <td>Activ\u00e9 <strong>OPcache<\/strong><\/td>\n      <td>Toujours activer dans les environnements en direct<\/td>\n    <\/tr>\n    <tr>\n      <td><code>opcache.validate_timestamps<\/code><\/td>\n      <td>0 (Prod)<\/td>\n      <td>D\u00e9sactive permanent <strong>Ch\u00e8ques<\/strong><\/td>\n      <td>Signaler les modifications via Reset\/Deploy<\/td>\n    <\/tr>\n    <tr>\n      <td><code>opcache.revalidate_freq<\/code><\/td>\n      <td>0 (Prod)<\/td>\n      <td>Pas de balayage \u00e0 intervalles r\u00e9guliers<\/td>\n      <td>\u00c9vite les invalidations impr\u00e9vues<\/td>\n    <\/tr>\n    <tr>\n      <td><code>opcache.memory_consumption<\/code><\/td>\n      <td>256 \u00e0 512 Mo<\/td>\n      <td>Plus d'espace pour le bytecode<\/td>\n      <td>Les grandes piles ont besoin de plus <strong>M\u00e9moire<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td><code>opcache.max_accelerated_files<\/code><\/td>\n      <td>15 000\u201330 000<\/td>\n      <td>Plus d'emplacements pour fichiers<\/td>\n      <td>Les grandes boutiques\/frameworks en profitent<\/td>\n    <\/tr>\n    <tr>\n      <td><code>opcache.interned_strings_buffer<\/code><\/td>\n      <td>16-32<\/td>\n      <td>R\u00e9duit les doublons<\/td>\n      <td>Utile dans de nombreux cas <strong>classes<\/strong>\/Espaces de noms<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Apr\u00e8s avoir apport\u00e9 des modifications, je red\u00e9marre rapidement PHP-FPM ou Apache et observe les indicateurs. Je peux ainsi voir imm\u00e9diatement si les cl\u00e9s et la m\u00e9moire sont suffisamment dimensionn\u00e9es. Si le taux de r\u00e9ussite atteint environ 100 %, la courbe de latence s'aplatit visiblement. Plus les chemins de d\u00e9ploiement et les valeurs de configuration sont coh\u00e9rents, plus les charges d'invalidation sont faibles. Cela r\u00e9duit les pics ainsi que les red\u00e9marrages apr\u00e8s un <a href=\"https:\/\/webhosting.de\/fr\/differences-entre-demarrage-a-froid-et-demarrage-a-chaud-dun-serveur-optimisation-des-performances\/\">D\u00e9marrage \u00e0 froid vs d\u00e9marrage \u00e0 chaud<\/a>.<\/p>\n\n<h2>Strat\u00e9gies de d\u00e9ploiement sans pics inutiles<\/h2>\n\n<p>Je mise sur un processus clair : d\u00e9ploiement du code, contr\u00f4les de sant\u00e9, puis ciblage. <code>opcache_reset()<\/code> ou sur mesure <code>opcache_invalidate()<\/code>-Appels avec <code>force=true<\/code>. La r\u00e9initialisation ne supprime pas seulement les marqueurs, mais nettoie compl\u00e8tement, ce qui est pratique pour les versions importantes. Pour les d\u00e9ploiements Blue-Green ou Symlink, je veille \u00e0 la coh\u00e9rence des chemins d'acc\u00e8s afin que le cache ne conserve aucune entr\u00e9e orpheline. Je ne d\u00e9clenche la r\u00e9initialisation que lorsque la nouvelle version est pr\u00eate et qu'une poign\u00e9e de requ\u00eates chaudes ont \u00e9t\u00e9 ex\u00e9cut\u00e9es. Cela me permet de r\u00e9partir les compilations co\u00fbteuses et de maintenir la <strong>Latence<\/strong> bas.<\/p>\n\n<p>Plusieurs parall\u00e8les <code>opcache_invalidate()<\/code>Les appels peuvent g\u00e9n\u00e9rer des conflits de verrouillage. Dans ce cas, je livre d'abord la nouvelle application en mode lecture seule, je pr\u00e9chauffe les itin\u00e9raires les plus importants, puis je r\u00e9initialise une fois et j'ouvre le trafic. Pour les backends API, je me concentre sur les points finaux \u00e0 fort trafic. Cela me permet d'atteindre les chemins chauds avant le trafic principal, d'\u00e9viter les effets de \u00ab thundering herd \u00bb et de r\u00e9duire les <strong>CPU<\/strong>-Peaks.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/php-opcache-techoffice-9482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configurations multi-locataires : isoler OPcache<\/h2>\n\n<p>Si plusieurs projets partagent le m\u00eame OPcache, une invalidation affecte tous les autres. C'est pourquoi je s\u00e9pare les pools PHP-FPM et leurs segments de cache par site. Cela emp\u00eache un d\u00e9ploiement de boutique en ligne d'augmenter la latence du blog ou une t\u00e2che cron de vider le cache d'une application. De plus, je d\u00e9finis des limites appropri\u00e9es par <strong>piscine<\/strong>, afin qu'aucune instance ne monopolise toute la m\u00e9moire. Ainsi, le taux de r\u00e9ussite par application reste constant et la <strong>Pointes<\/strong> restent locaux.<\/p>\n\n<p>La coh\u00e9rence des chemins d'acc\u00e8s joue \u00e9galement un r\u00f4le : si la structure r\u00e9elle des chemins d'acc\u00e8s change \u00e0 chaque d\u00e9ploiement, un chemin d'acc\u00e8s cible stable et versionn\u00e9 qui ne g\u00e9n\u00e8re pas \u00e0 chaque fois de nouvelles cl\u00e9s de cache est utile. Je r\u00e9serve les autoloads Composer \u00e0 cet effet et \u00e9vite ainsi des modifications inutiles sur des milliers de fichiers. Moins de diff signifie moins de blocs de bytecode \u00e0 invalider. Cela r\u00e9duit consid\u00e9rablement les difficult\u00e9s li\u00e9es \u00e0 la migration lors des mises \u00e0 jour et stabilise le trafic en direct.<\/p>\n\n<h2>WordPress, Shopware et autres : remarques sp\u00e9cifiques<\/h2>\n\n<p>Avec WordPress, je combine OPcache avec un cache objet (par exemple Redis) afin de soulager simultan\u00e9ment l'ex\u00e9cution PHP et les requ\u00eates de base de donn\u00e9es. Pour Shopware et les boutiques similaires, j'utilise <code>opcache.max_accelerated_files<\/code> suffisamment \u00e9lev\u00e9e, car de nombreux fichiers sont concern\u00e9s. Je d\u00e9sactive les v\u00e9rifications d'horodatage et veille \u00e0 ce que les <strong>r\u00e9initialisations<\/strong> directement apr\u00e8s le d\u00e9ploiement. Je r\u00e9chauffe les th\u00e8mes, les plugins et les mises \u00e0 jour Composer de mani\u00e8re cibl\u00e9e sur les itin\u00e9raires les plus fr\u00e9quent\u00e9s. Cela permet de minimiser les d\u00e9marrages \u00e0 froid et de maintenir le <strong>D\u00e9bit<\/strong> stable.<\/p>\n\n<p>En mode d\u00e9veloppement, la v\u00e9rification de l'horodatage peut rester active, par exemple avec <code>opcache.revalidate_freq=2<\/code>. Cela acc\u00e9l\u00e8re les it\u00e9rations locales sans surcharger les syst\u00e8mes de production. Dans les environnements de staging, je reproduis la configuration en direct afin d'\u00e9viter les surprises. Cela me permet d'identifier rapidement les goulots d'\u00e9tranglement et de d\u00e9placer les compilations co\u00fbteuses hors des p\u00e9riodes de trafic r\u00e9el des utilisateurs.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/php_opcache_desk_4927.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemple pratique et strat\u00e9gie de mesure<\/h2>\n\n<p>Un sch\u00e9ma typique : 16 requ\u00eates sont trait\u00e9es en ~200 ms, la 17e passe \u00e0 ~1,2 s. Dans les traces, je reconnais plusieurs compilations de fichiers qui ont \u00e9t\u00e9 d\u00e9clench\u00e9es par une pr\u00e9c\u00e9dente <strong>Invalidation<\/strong> ont \u00e9t\u00e9 d\u00e9clench\u00e9s. Apr\u00e8s une r\u00e9initialisation et un r\u00e9chauffement cibl\u00e9s, les latences reviennent \u00e0 leur valeur normale. Des am\u00e9liorations de 30 \u00e0 70 % sont r\u00e9alistes si OPcache fonctionne correctement et si les \u00e9checs sont rares. Des rapports pratiques montrent en outre de l\u00e9gers gains par requ\u00eate lorsque les v\u00e9rifications d'horodatage restent d\u00e9sactiv\u00e9es.<\/p>\n\n<p>Je mesure trois choses en parall\u00e8le : le taux de r\u00e9ussite, les cl\u00e9s utilis\u00e9es et l'utilisation de la m\u00e9moire. Si le taux de r\u00e9ussite diminue, j'augmente le nombre d'emplacements ou je r\u00e9duis les modifications inutiles. Si l'utilisation de la m\u00e9moire atteint son maximum, j'attribue des m\u00e9gaoctets suppl\u00e9mentaires et je v\u00e9rifie les anciennes entr\u00e9es. En cas de pics inhabituels dans la courbe, je filtre les plages horaires avec des d\u00e9ploiements, des t\u00e2ches cron ou des vidages de cache. Cela me permet de mettre en \u00e9vidence la cause et d'\u00e9viter les <strong>Pointes<\/strong> dans le futur.<\/p>\n\n<h2>Erreurs fr\u00e9quentes \u2013 et solutions imm\u00e9diates<\/h2>\n\n<p>Beaucoup de parall\u00e8les <code>opcache_invalidate()<\/code>Les appels -Calls entra\u00eenent des conflits de verrouillage et donnent <code>false<\/code> Je les remplace dans les scripts de d\u00e9ploiement productifs par un seul <code>opcache_reset()<\/code> apr\u00e8s le r\u00e9chauffement et \u00e9conomise ainsi <strong>Locks<\/strong>. Si le cache est \u201e plein \u201c, j'augmente <code>opcache.memory_consumption<\/code> et <code>opcache.max_accelerated_files<\/code> et v\u00e9rifie si des fichiers inutiles se retrouvent dans le cache. En cas de latence instable, j'analyse les tampons de cha\u00eenes et traite les \u00e9ventuels <a href=\"https:\/\/webhosting.de\/fr\/fragmentation-de-la-memoire-hebergement-web-php-mysql-optimisation-flux-doctets\/\">Fragmentation de la m\u00e9moire<\/a>. Si plusieurs sites acc\u00e8dent au m\u00eame pool, je les s\u00e9pare syst\u00e9matiquement afin que les invalidations ne d\u00e9clenchent pas de r\u00e9actions en cha\u00eene.<\/p>\n\n<p>Si le probl\u00e8me survient apr\u00e8s une publication, je v\u00e9rifie les chemins d'acc\u00e8s, les liens symboliques et l'autochargeur. Des chemins d'acc\u00e8s diff\u00e9rents pour des classes identiques g\u00e9n\u00e8rent des cl\u00e9s de cache suppl\u00e9mentaires et augmentent la m\u00e9moire. Je maintiens donc le chemin d'acc\u00e8s au projet stable et ne fais tourner que les sous-dossiers de version. Ensuite, je nettoie avec Reset et laisse les routes chaudes charger les blocs de bytecode les plus importants. Je d\u00e9place ainsi la charge vers un moment contr\u00f4l\u00e9 avec peu de <strong>Trafic<\/strong>.<\/p>\n\n<h2>OPcache et PHP 8.x : JIT, pr\u00e9chargement et leurs effets secondaires<\/h2>\n\n<p>Le compilateur JIT est disponible depuis PHP 8. Je ne l'active qu'avec prudence dans les charges de travail Web classiques. Bien que le JIT puisse aider dans les boucles gourmandes en ressources CPU, il augmente la complexit\u00e9 et les besoins en m\u00e9moire. En cas d'invalidations, les fonctions concern\u00e9es doivent \u00eatre recompil\u00e9es avec le JIT, ce qui peut amplifier les pics. Pour les API avec de nombreuses requ\u00eates courtes, les gains sont souvent marginaux, tandis que les co\u00fbts de d\u00e9marrage \u00e0 froid augmentent. Je teste donc JIT s\u00e9par\u00e9ment et m'assure que les tailles de tampon n'entra\u00eenent pas de <strong>Red\u00e9marrages<\/strong> plomb.<\/p>\n\n<p>Le pr\u00e9chargement est un outil puissant contre les erreurs : je pr\u00e9charge un ensemble s\u00e9lectionn\u00e9 de classes centrales au d\u00e9marrage de PHP. Cela r\u00e9duit consid\u00e9rablement le nombre de premi\u00e8res compilations. En m\u00eame temps, le pr\u00e9chargement n\u00e9cessite des d\u00e9ploiements disciplin\u00e9s, car les fichiers pr\u00e9charg\u00e9s sont li\u00e9s \u00e0 des chemins d'acc\u00e8s et \u00e0 l'ABI. Si les chemins d'acc\u00e8s changent, le processus SAPI doit \u00eatre red\u00e9marr\u00e9 proprement. Je limite le pr\u00e9chargement aux paquets de base vraiment stables (par exemple, le c\u0153ur du framework) et j'ignore les \u00e9l\u00e9ments volatils tels que les th\u00e8mes ou les plugins. Cela me permet de b\u00e9n\u00e9ficier de chemins d'acc\u00e8s chauds sans avoir \u00e0 recharger tout le syst\u00e8me \u00e0 froid \u00e0 chaque mise \u00e0 jour mineure.<\/p>\n\n<h2>R\u00e9duire au minimum les compositeurs, les chargeurs automatiques et les acc\u00e8s aux fichiers<\/h2>\n\n<p>J'optimise syst\u00e9matiquement l'autochargeur. Une carte de classe faisant autorit\u00e9 r\u00e9duit <code>stat()<\/code>-Appels et inclusions inutiles. Moins il y a de fichiers concern\u00e9s par requ\u00eate, moins les d\u00e9g\u00e2ts sont importants en cas d'erreur. De m\u00eame, je conserve les fichiers g\u00e9n\u00e9r\u00e9s (par exemple les proxys) stables, au lieu de les r\u00e9\u00e9crire \u00e0 chaque build avec des horodatages diff\u00e9rents. Moins de diff\u00e9rences signifie moins d'invalidations.<\/p>\n\n<p>Le cache Realpath interne de PHP constitue un autre levier. Des valeurs g\u00e9n\u00e9reuses pour la taille et le TTL r\u00e9duisent les recherches dans le syst\u00e8me de fichiers. Cela diminue le nombre de v\u00e9rifications d'horodatage, m\u00eame si celles-ci sont d\u00e9sactiv\u00e9es en production, et soulage le syst\u00e8me lors du pr\u00e9chauffage. Le cache Realpath aide notamment \u00e0 \u00e9viter les latences inutiles sur les volumes de conteneurs ou les partages r\u00e9seau.<\/p>\n\n<h2>Influences du syst\u00e8me de fichiers : NFS, liens symboliques et protection contre les mises \u00e0 jour<\/h2>\n\n<p>Les d\u00e9calages d'horloge et les incoh\u00e9rences sont plus fr\u00e9quents sur les syst\u00e8mes de fichiers r\u00e9seau. Je planifie les d\u00e9ploiements de mani\u00e8re strictement atomique et \u00e9vite les situations mixtes o\u00f9 s'entrem\u00ealent anciens et nouveaux fichiers. L'option de protection contre les mises \u00e0 jour emp\u00eache la compilation imm\u00e9diate des fichiers en cours d'\u00e9criture jusqu'\u00e0 ce que le processus d'\u00e9criture soit termin\u00e9 en toute s\u00e9curit\u00e9. Dans les environnements avec des commutateurs symlink atomiques, je r\u00e8gle le temps de protection sur une valeur faible afin de ne pas retarder artificiellement les commutations cibl\u00e9es.<\/p>\n\n<p>Les liens symboliques influencent les cl\u00e9s de cache. Je consid\u00e8re donc que le chemin visible pour PHP est stable et je ne change que le sous-dossier de version. Ainsi, les cl\u00e9s restent valides et le cache ne rejette pas inutilement le bytecode. Dans le cas de chemins fortement imbriqu\u00e9s, je v\u00e9rifie en outre si diff\u00e9rents chemins de r\u00e9solution m\u00e8nent \u00e0 la m\u00eame destination \u2013 montages coh\u00e9rents et uniformes. <code>include_path<\/code>Les param\u00e8tres permettent d'\u00e9viter les doublons.<\/p>\n\n<h2>Approfondir le diagnostic : interpr\u00e9ter correctement les champs d'\u00e9tat<\/h2>\n\n<p>\u00c0 l'adresse suivante : <code>opcache_get_status()<\/code> Outre le taux de r\u00e9ussite, trois domaines m'int\u00e9ressent particuli\u00e8rement : <strong>memory_usage<\/strong> (partie utilis\u00e9e, libre et fragment\u00e9e), <strong>opcache_statistics<\/strong> (Misses, Blacklist-Hits, max_cached_keys) et les indicateurs <strong>restart_pending<\/strong>\/<strong>restart_in_progress<\/strong>. Si les \u00e9checs sans d\u00e9ploiement s'accumulent, cela signifie que le cache est trop petit ou que la liste des fichiers est \u00e9puis\u00e9e. Si la proportion de d\u00e9chets d\u00e9passe un seuil critique, OPcache d\u00e9clenche des <strong>Red\u00e9marrages<\/strong> \u2013 cela se voit aux indicateurs \u00ab En attente \u00bb\/\u00ab En cours \u00bb et explique les pics r\u00e9currents dans la courbe de latence.<\/p>\n\n<p>Pour analyser les causes, je corr\u00e8le ces champs avec les m\u00e9triques h\u00f4te : pics CPU, E\/S disque, changements de contexte. Une phase avec un CPU syst\u00e8me \u00e9lev\u00e9 et un r\u00e9seau mod\u00e9r\u00e9 indique des conflits de verrouillage dans la m\u00e9moire partag\u00e9e ou dans le syst\u00e8me de fichiers. J'augmente alors les slots, la m\u00e9moire et les tampons de cha\u00eenes avant d'optimiser au niveau du code. Important : une r\u00e9initialisation sur simple suspicion est un scalpel, pas un marteau. Je la planifie et j'observe les effets imm\u00e9diatement apr\u00e8s.<\/p>\n\n<h2>PHP-FPM et contr\u00f4le du d\u00e9ploiement<\/h2>\n\n<p>OPcache se trouve dans l'espace d'adressage du processus SAPI. Avec PHP-FPM, cela signifie qu'un red\u00e9marrage complet vide le cache, tandis qu'un rechargement en douceur le maintient g\u00e9n\u00e9ralement stable. J'\u00e9vite les red\u00e9marrages \u00ab big bang \u00bb et je lance les workers progressivement afin que tous les processus ne d\u00e9marrent pas \u00e0 froid en m\u00eame temps. Pendant les pics de charge, je limite \u00e9galement les recompilations parall\u00e8les \u00e0 court terme, par exemple en coordonnant les requ\u00eates de pr\u00e9chauffage avec une faible <strong>Concurrence<\/strong>.<\/p>\n\n<p>Le nombre de travailleurs influence l'effet des pics. Un trop grand nombre de processus simultan\u00e9s peut d\u00e9clencher une avalanche de compilations en cas d'invalidations. J'ajuste donc le nombre de processus en fonction du nombre de processeurs et du temps de service moyen dans des conditions normales. L'objectif est de maintenir un parall\u00e9lisme suffisant sans d\u00e9clencher de vagues de compilations.<\/p>\n\n<h2>Environnements conteneurs et cloud<\/h2>\n\n<p>Dans les conteneurs \u00e0 courte dur\u00e9e de vie, les d\u00e9marrages \u00e0 froid sont naturellement plus fr\u00e9quents. Je mise sur des Readiness Gates qui ne passent \u00e0 \u201e pr\u00eat \u201c qu'apr\u00e8s un r\u00e9chauffement cibl\u00e9. Les d\u00e9ploiements avec un faible renouvellement simultan\u00e9 \u00e9vitent que de nombreux nouveaux pods construisent le bytecode en m\u00eame temps. Dans les configurations multizones, je teste \u00e9galement le chemin de pr\u00e9chauffage par zone afin d'\u00e9viter que les pics de latence ne se concentrent g\u00e9ographiquement.<\/p>\n\n<p>Pour les images de build, il est int\u00e9ressant de monter le code de l'application en lecture seule et de d\u00e9sactiver les v\u00e9rifications d'horodatage. Cela permet de stabiliser le cache et de clarifier la diff\u00e9rence entre le build et le runtime. Si vous faites tourner fr\u00e9quemment des conteneurs, je r\u00e9partis les pr\u00e9chauffages par vagues : d'abord les points d'acc\u00e8s chauds, puis les chemins secondaires. Cela permet de lisser la courbe et de prot\u00e9ger contre les r\u00e9actions en cha\u00eene sur le <strong>CPU<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/php-opcache-invalidierung-1472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Travailleurs CLI, t\u00e2ches cron et processus en arri\u00e8re-plan<\/h2>\n\n<p>Les processus worker de longue dur\u00e9e b\u00e9n\u00e9ficient en partie de l'activation de l'OPcache dans le contexte CLI. Je teste cela pour les consommateurs de file d'attente et les planificateurs qui ex\u00e9cutent de nombreuses t\u00e2ches identiques dans un processus. Il est important de faire la distinction suivante : les t\u00e2ches cron de courte dur\u00e9e n'en tirent que peu d'avantages, car leur cycle de vie est trop court pour utiliser le cache de mani\u00e8re judicieuse. De plus, les t\u00e2ches CLI ne doivent pas d\u00e9clencher involontairement une r\u00e9initialisation globale. Par mesure de s\u00e9curit\u00e9, je bloque les fonctions OPcache via une restriction API et je r\u00e9gule les invalidations uniquement via le d\u00e9ploiement Web.<\/p>\n\n<h2>R\u00e9glage fin : param\u00e8tres avanc\u00e9s et pi\u00e8ges \u00e0 \u00e9viter<\/h2>\n\n<p>Quelques param\u00e8tres agissent souvent en arri\u00e8re-plan : la proportion autoris\u00e9e de blocs gaspill\u00e9s d\u00e9termine quand OPcache red\u00e9marre en interne. Si la valeur est trop faible ou si la m\u00e9moire est insuffisante, des red\u00e9marrages fr\u00e9quents en arri\u00e8re-plan avec des pics de timing peuvent se produire. Je pr\u00e9f\u00e8re consacrer un peu plus de m\u00e9moire partag\u00e9e plut\u00f4t que de risquer des pouss\u00e9es de fragmentation inaper\u00e7ues. La question de savoir si les commentaires sont conserv\u00e9s dans le bytecode est tout aussi importante. Certains frameworks utilisent des docblocks ; les supprimer permet d'\u00e9conomiser de la m\u00e9moire, mais peut endommager certaines fonctionnalit\u00e9s \u2013 je teste cela d\u00e9lib\u00e9r\u00e9ment.<\/p>\n\n<p>Pour les bases de code volumineuses, je recommande de maintenir une liste noire des fichiers qui ne doivent pas \u00eatre mis en cache (par exemple, les artefacts g\u00e9n\u00e9r\u00e9s fr\u00e9quemment). Chaque octet en moins de masse volatile augmente la stabilit\u00e9. Et si l'utilisation de pages de code avec de grandes pages m\u00e9moire est possible, cela peut r\u00e9duire la pression TLB c\u00f4t\u00e9 CPU, mais dans la pratique, cela ne fonctionne que si l'h\u00f4te est correctement configur\u00e9 \u00e0 cet effet. Je prends cette d\u00e9cision pour chaque serveur et mesure l'effet, au lieu de l'activer de mani\u00e8re globale.<\/p>\n\n<h2>Strat\u00e9gies chaleureuses : cibl\u00e9es plut\u00f4t que dispers\u00e9es<\/h2>\n\n<p>Un bon \u00e9chauffement se concentre sur les chemins d'acc\u00e8s fr\u00e9quents. Je simule les flux d'utilisateurs typiques : page d'accueil, listes de produits, d\u00e9tails des produits, paiement, connexion, points de terminaison API \u00e0 haute fr\u00e9quence. Quelques requ\u00eates suffisent par itin\u00e9raire, \u00e0 condition qu'elles s'ex\u00e9cutent en s\u00e9rie ou avec un faible parall\u00e9lisme. Cela \u00e9vite les verrous inutiles et permet au cache de se remplir progressivement. Dans les syst\u00e8mes dynamiques, je r\u00e9p\u00e8te le r\u00e9chauffement apr\u00e8s un red\u00e9marrage, mais pas apr\u00e8s chaque petite modification. Il est important de s\u00e9parer le temps de compilation et le temps d'ex\u00e9cution.<\/p>\n\n<h2>Guide pratique : lancement sans pics en 8 \u00e9tapes<\/h2>\n\n<ol>\n  <li>Optimiser l'autochargeur et minimiser les diff\u00e9rences de compilation (pas de modifications inutiles des horodatages).<\/li>\n  <li>Fournir le code atomique, maintenir les chemins d'acc\u00e8s stables, pr\u00e9parer le commutateur de lien symbolique.<\/li>\n  <li>Activer les contr\u00f4les de disponibilit\u00e9, maintenir le trafic \u00e0 distance dans un premier temps.<\/li>\n  <li>Effectuer un pr\u00e9chauffage cibl\u00e9 des chemins d'acc\u00e8s fr\u00e9quents avec un faible parall\u00e9lisme.<\/li>\n  <li>Cibl\u00e9 <code>opcache_reset()<\/code> lorsque la nouvelle version sera enti\u00e8rement pr\u00eate.<\/li>\n  <li>Court \u00e9chauffement pour les itin\u00e9raires secondaires, puis ouverture de Readiness.<\/li>\n  <li>Surveiller le taux de r\u00e9ussite, les cl\u00e9s, la m\u00e9moire et le CPU.<\/li>\n  <li>En cas d'anomalies : r\u00e9ajuster les emplacements\/la m\u00e9moire, v\u00e9rifier les chemins d'acc\u00e8s, \u00e9viter les conflits de verrouillage.<\/li>\n<\/ol>\n\n<p>Gr\u00e2ce \u00e0 ce processus, je r\u00e9partis dans le temps les op\u00e9rations de compilation co\u00fbteuses et j'\u00e9vite que les premiers utilisateurs r\u00e9els ne paient le prix d'un cache froid. Des d\u00e9cisions telles que la d\u00e9sactivation des v\u00e9rifications d'horodatage en production garantissent que le contr\u00f4le repose sur le script de d\u00e9ploiement et non sur le syst\u00e8me de fichiers.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/01\/php-opcache-performance-peak-6472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n\n<p>Les invalidations sont n\u00e9cessaires, mais elles entra\u00eenent des recompilations co\u00fbteuses qui peuvent s'av\u00e9rer <strong>Performance<\/strong>-Spitzen zeigen. Je d\u00e9sactive les v\u00e9rifications d'horodatage en production, je dimensionne g\u00e9n\u00e9reusement la m\u00e9moire et les emplacements de fichiers et je planifie des r\u00e9initialisations autour des d\u00e9ploiements. Avec un pr\u00e9chauffage, des chemins stables et des pools isol\u00e9s, le taux de r\u00e9ussite reste \u00e9lev\u00e9 et la latence faible. La surveillance du taux de r\u00e9ussite, des cl\u00e9s et de la m\u00e9moire montre si les param\u00e8tres sont efficaces. En tenant compte de ces r\u00e9glages, vous r\u00e9duisez sensiblement les \u00e9checs et maintenez la <strong>Temps de r\u00e9ponse<\/strong> fiable faible.<\/p>","protected":false},"excerpt":{"rendered":"<p>L'invalidation de PHP Opcache provoque des pics de performance. D\u00e9couvrez les causes et les conseils d'optimisation de l'h\u00e9bergement pour une performance PHP stable.<\/p>","protected":false},"author":1,"featured_media":16462,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-16469","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1563","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"PHP Opcache Invalidierung","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"16462","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16469","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=16469"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16469\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/16462"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=16469"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=16469"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=16469"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}