{"id":16517,"date":"2026-01-03T18:21:29","date_gmt":"2026-01-03T17:21:29","guid":{"rendered":"https:\/\/webhosting.de\/php-execution-limits-auswirkungen-tuning-serverflux\/"},"modified":"2026-01-03T18:21:29","modified_gmt":"2026-01-03T17:21:29","slug":"limites-dexecution-php-consequences-et-optimisation-de-serverflux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/php-execution-limits-auswirkungen-tuning-serverflux\/","title":{"rendered":"Limites d'ex\u00e9cution PHP : impact r\u00e9el sur les performances et la stabilit\u00e9"},"content":{"rendered":"<p>Les limites d'ex\u00e9cution PHP ont une influence notable sur la vitesse de traitement des requ\u00eates et sur la fiabilit\u00e9 d'un serveur web soumis \u00e0 une charge importante. Je vais vous montrer quelles sont ces limites. <strong>limites de temps<\/strong> freinent r\u00e9ellement, comment ils interagissent avec la m\u00e9moire et le processeur, et quels param\u00e8tres permettent de garantir la stabilit\u00e9 et la rapidit\u00e9 de sites tels que WordPress et les boutiques en ligne.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Temps d'ex\u00e9cution<\/strong> r\u00e9gule la dur\u00e9e d'ex\u00e9cution des scripts et d\u00e9termine les d\u00e9lais d'attente et les taux d'erreur.<\/li>\n  <li><strong>Limite de m\u00e9moire<\/strong> et le temps d'ex\u00e9cution interagissent et modifient les temps de chargement et la stabilit\u00e9.<\/li>\n  <li><strong>Optimisation de l'h\u00e9bergement<\/strong> (php.ini, PHP\u2011FPM) emp\u00eache les blocages dus \u00e0 des scripts trop longs et \u00e0 un nombre trop important de workers.<\/li>\n  <li><strong>WordPress\/Boutique<\/strong> n\u00e9cessite des limites g\u00e9n\u00e9reuses pour les importations, les sauvegardes, les mises \u00e0 jour et les t\u00e2ches cron.<\/li>\n  <li><strong>Suivi<\/strong> de l'\u00e9tat du CPU, de la RAM et du FPM permet de d\u00e9tecter les goulots d'\u00e9tranglement et les limites incorrectes.<\/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-performance-limit-8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Principes fondamentaux : ce que mesure r\u00e9ellement le temps d'ex\u00e9cution<\/h2>\n\n<p>La directive <strong>max_execution_time<\/strong> D\u00e9termine le nombre maximal de secondes pendant lesquelles un script PHP peut effectuer des calculs avant d'\u00eatre interrompu. Le minuteur ne d\u00e9marre que lorsque PHP commence \u00e0 ex\u00e9cuter le script, et non lors du t\u00e9l\u00e9chargement du fichier ou pendant que le serveur web accepte la requ\u00eate. Les requ\u00eates \u00e0 la base de donn\u00e9es, les boucles et le rendu des mod\u00e8les sont enti\u00e8rement pris en compte dans le temps, ce qui est particuli\u00e8rement perceptible avec un processeur moins puissant. Si un script atteint la limite, PHP arr\u00eate l'ex\u00e9cution et envoie une erreur telle que \u201e Maximum execution time exceeded \u201c. Je constate souvent dans les journaux qu'un pr\u00e9tendu blocage est simplement d\u00fb au <strong>D\u00e9lai d'attente<\/strong> est d\u00fb \u00e0 une sp\u00e9cification trop restrictive.<\/p>\n\n<p>Les valeurs par d\u00e9faut typiques varient entre 30 et 300 secondes, l'h\u00e9bergement mutualis\u00e9 \u00e9tant g\u00e9n\u00e9ralement plus limit\u00e9. Ces param\u00e8tres prot\u00e8gent le serveur contre les boucles infinies et les processus bloquants qui ralentiraient les autres utilisateurs. Cependant, des valeurs trop strictes affectent les t\u00e2ches normales telles que la g\u00e9n\u00e9ration d'images ou l'analyse XML, qui prennent plus de temps lorsque le trafic est intense. Des limites plus \u00e9lev\u00e9es permettent de sauver les t\u00e2ches gourmandes en ressources, mais peuvent surcharger une instance si plusieurs requ\u00eates longues sont ex\u00e9cut\u00e9es simultan\u00e9ment. Dans la pratique, je teste par \u00e9tapes et \u00e9galise le temps d'ex\u00e9cution avec <strong>M\u00e9moire<\/strong>, CPU et parall\u00e9lisme.<\/p>\n\n<h2>Impacts r\u00e9els : performances, taux d'erreur et exp\u00e9rience utilisateur<\/h2>\n\n<p>Un niveau trop bas <strong>limite de temps<\/strong> provoque des interruptions brutales que les utilisateurs per\u00e7oivent comme des pages d\u00e9fectueuses. Les mises \u00e0 jour WordPress, les optimisations d'images en masse ou les exportations WooCommerce volumineuses atteignent rapidement leurs limites, ce qui augmente les temps de chargement et compromet les transactions. Si j'augmente le temps d'ex\u00e9cution \u00e0 300 secondes et que je d\u00e9ploie OPcache en parall\u00e8le, les temps de r\u00e9ponse diminuent sensiblement, car PHP compile moins. Lorsque les limites sont serr\u00e9es, j'observe \u00e9galement une charge CPU plus \u00e9lev\u00e9e, car les scripts red\u00e9marrent plusieurs fois au lieu de s'ex\u00e9cuter correctement une seule fois. L'exp\u00e9rience v\u00e9cue <strong>Performance<\/strong> ne d\u00e9pend donc pas seulement du code, mais aussi directement des valeurs limites fix\u00e9es de mani\u00e8re judicieuse.<\/p>\n\n<p>Des valeurs trop \u00e9lev\u00e9es ne sont pas une bonne chose, car les processus longs occupent les PHP Workers et bloquent les autres requ\u00eates. Sur les syst\u00e8mes partag\u00e9s, cela cr\u00e9e un goulot d'\u00e9tranglement pour tous les voisins ; sur les VPS ou les serveurs d\u00e9di\u00e9s, la machine peut basculer en mode swap. Je m'en tiens \u00e0 une r\u00e8gle empirique : aussi \u00e9lev\u00e9 que n\u00e9cessaire, aussi bas que possible, et toujours en combinaison avec la mise en cache. Si un processus devient r\u00e9guli\u00e8rement tr\u00e8s long, je le d\u00e9place vers un Queue Worker ou je l'ex\u00e9cute comme une t\u00e2che planifi\u00e9e. Ainsi, les requ\u00eates frontales restent courtes, tandis que les t\u00e2ches gourmandes en ressources sont ex\u00e9cut\u00e9es dans le <strong>Contexte<\/strong> courir.<\/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_execution_limits_3891.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pratique : exploiter WordPress et Shop Stacks sans d\u00e9lais d'expiration<\/h2>\n\n<p>WordPress, avec ses nombreux plugins et constructeurs de pages, b\u00e9n\u00e9ficie de 256 \u00e0 512 Mo. <strong>M\u00e9moire<\/strong> et 300 secondes de temps d'ex\u00e9cution, en particulier pour les importations de m\u00e9dias, les sauvegardes et les t\u00e2ches de sauvegarde. La compilation des th\u00e8mes, les appels REST et les \u00e9v\u00e9nements Cron sont mieux r\u00e9partis lorsque OPcache est actif et qu'un cache d'objets stocke les r\u00e9sultats. Pour WooCommerce, je prends \u00e9galement en compte les requ\u00eates DB longues et les requ\u00eates API vers les services de paiement et d'exp\u00e9dition. Une partie de la stabilit\u00e9 provient d'une s\u00e9lection rigoureuse des plugins : moins de redondance, pas d'add-ons orphelins. Si vous avez beaucoup de requ\u00eates simultan\u00e9es, vous devriez <a href=\"https:\/\/webhosting.de\/fr\/php-workers-hosting-goulot-detranglement-guide-balance\/\">Dimensionner correctement les PHP Workers<\/a>, afin que les pages frontales disposent toujours d'un <strong>Processus<\/strong> re\u00e7u.<\/p>\n\n<p>Les syst\u00e8mes de boutique avec sitemaps, flux et synchronisation ERP g\u00e9n\u00e8rent des pics qui d\u00e9passent les limites standard. Les routines d'importation n\u00e9cessitent plus de temps d'ex\u00e9cution, mais je les encapsule dans des t\u00e2ches qui s'ex\u00e9cutent en dehors des requ\u00eates Web. Si cela n'est pas possible, je d\u00e9finis des plages horaires pendant les heures creuses. Cela me permet de soulager le trafic frontal et de minimiser les collisions avec les campagnes ou les \u00e9v\u00e9nements commerciaux. Un plan clair r\u00e9duit <strong>Erreur<\/strong> perceptible et prot\u00e8ge les flux de conversion.<\/p>\n\n<h2>Optimisation de l'h\u00e9bergement : php.ini, OPcache et valeurs limites pertinentes<\/h2>\n\n<p>Je commence par des valeurs conservatrices et les augmente de mani\u00e8re cibl\u00e9e : max_execution_time = 300, memory_limit = 256M, OPcache actif et cache objet au niveau de l'application. Ensuite, j'observe les pics de charge et j'ajuste par petites \u00e9tapes, au lieu d'augmenter les valeurs de mani\u00e8re al\u00e9atoire. <strong>Limites<\/strong> Pour Apache, .htaccess peut remplacer les valeurs ; pour Nginx, ce sont les configurations de pool et les param\u00e8tres PHP-FPM qui s'en chargent. Il est important de recharger apr\u00e8s chaque modification afin que les nouvelles sp\u00e9cifications prennent effectivement effet. Ceux qui connaissent leur environnement tirent davantage parti du m\u00eame mat\u00e9riel. <strong>Performance<\/strong>.<\/p>\n\n<p>Dans le cadre du monitoring, je surveille le 95e centile des temps de r\u00e9ponse, les taux d'erreur et l'utilisation de la RAM par processus. Si une t\u00e2che d\u00e9passe r\u00e9guli\u00e8rement 120 secondes, je v\u00e9rifie les chemins d'acc\u00e8s au code, les plans de requ\u00eate et les services externes. Un code compact avec des conditions d'interruption claires r\u00e9duit consid\u00e9rablement les temps d'ex\u00e9cution. De plus, il est utile de coordonner les limites de t\u00e9l\u00e9chargement, post_max_size et max_input_vars afin que les requ\u00eates n'\u00e9chouent pas pour des raisons secondaires. Une bonne configuration emp\u00eache les r\u00e9actions en cha\u00eene. <strong>Timeouts<\/strong> et les nouvelles tentatives.<\/p>\n\n<h2>PHP\u2011FPM : processus, parall\u00e9lisme et pm.max_children<\/h2>\n\n<p>Le nombre de processus PHP simultan\u00e9s d\u00e9termine le nombre de requ\u00eates pouvant \u00eatre trait\u00e9es en parall\u00e8le. Trop peu de workers entra\u00eenent des files d'attente, trop nombreux, ils occupent trop de RAM et forcent le syst\u00e8me \u00e0 effectuer un swap. J'\u00e9quilibre pm.max_children par rapport \u00e0 memory_limit et \u00e0 l'utilisation moyenne par processus, puis je teste avec du trafic r\u00e9el. Le sweet spot maintient les latences \u00e0 un niveau bas sans surcharger l'h\u00f4te. <strong>swap<\/strong> . Ceux qui souhaitent approfondir le sujet trouveront sur <a href=\"https:\/\/webhosting.de\/fr\/php-fpm-gestion-des-processus-pm-max-children-optimiser-core\/\">Optimiser pm.max_children<\/a> approches concr\u00e8tes pour contr\u00f4ler la <strong>Travailleur<\/strong>.<\/p>\n\n<p>Outre le nombre pur et simple, les param\u00e8tres de d\u00e9marrage tels que pm.start_servers et pm.min_spare_servers sont \u00e9galement importants. Si les enfants sont g\u00e9n\u00e9r\u00e9s de mani\u00e8re trop agressive, cela d\u00e9t\u00e9riore les temps de d\u00e9marrage \u00e0 froid et la fragmentation. Je v\u00e9rifie \u00e9galement la dur\u00e9e pendant laquelle les requ\u00eates restent occup\u00e9es, en particulier pour les API externes. Une tol\u00e9rance de d\u00e9lai d'expiration trop \u00e9lev\u00e9e mobilise des ressources qui seraient mieux utilis\u00e9es pour de nouvelles requ\u00eates. Au final, c'est la dur\u00e9e de s\u00e9jour courte qui compte. <strong>Demande<\/strong> plus que la dur\u00e9e maximale.<\/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-execution-limits-performance-2817.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interaction : temps d'ex\u00e9cution, limite de m\u00e9moire et collecte des d\u00e9chets<\/h2>\n\n<p>Une m\u00e9moire RAM insuffisante oblige \u00e0 effectuer fr\u00e9quemment un ramassage des ordures, ce qui consomme du temps de calcul et rapproche les scripts de la <strong>D\u00e9lai d'attente<\/strong> pousse. Si j'augmente mod\u00e9r\u00e9ment la limite de m\u00e9moire, le nombre de cycles GC diminue et le temps d'ex\u00e9cution semble \u201e plus long \u201c. Cela vaut particuli\u00e8rement pour les processus gourmands en donn\u00e9es tels que les analyseurs syntaxiques, les exportations ou les transformations d'images. Pour les t\u00e9l\u00e9chargements, j'harmonise upload_max_filesize, post_max_size et max_input_vars afin que les requ\u00eates ne soient pas rejet\u00e9es en raison de limites d'entr\u00e9e. Je r\u00e9sume les effets de la RAM de mani\u00e8re plus approfondie dans cet aper\u00e7u : <a href=\"https:\/\/webhosting.de\/fr\/limite-de-memoire-php-effets-sur-les-performances-optimisation-de-lhebergement-consommation-de-ram\/\">Limite de m\u00e9moire et consommation de RAM<\/a>, qui pr\u00e9sente les aspects pratiques <strong>liens<\/strong> mis en lumi\u00e8re.<\/p>\n\n<p>OPcache agit \u00e9galement comme un multiplicateur : moins de compilations signifie moins de temps CPU par requ\u00eate. Un cache d'objets r\u00e9duit les lectures lourdes de la base de donn\u00e9es et stabilise les temps de r\u00e9ponse. Ainsi, un cr\u00e9neau horaire restreint se transforme en cycles stables, sans augmenter davantage la limite. Enfin, des index optimis\u00e9s et des requ\u00eates all\u00e9g\u00e9es acc\u00e9l\u00e8rent l'obtention de la r\u00e9ponse. Chaque milliseconde gagn\u00e9e dans l'application soulage le <strong>Valeurs limites<\/strong> au niveau du syst\u00e8me.<\/p>\n\n<h2>Mesure et surveillance : les donn\u00e9es plut\u00f4t que l'intuition<\/h2>\n\n<p>Je mesure d'abord, puis je modifie : le statut FPM, les journaux d'acc\u00e8s, les journaux d'erreurs et les m\u00e9triques telles que CPU, RAM et E\/S apportent de la clart\u00e9. Les 95e et 99e centiles sont particuli\u00e8rement utiles, car ils permettent de mettre en \u00e9vidence les valeurs aberrantes et d'objectiver les optimisations. Apr\u00e8s chaque ajustement, je v\u00e9rifie si les taux d'erreur diminuent et si les temps de r\u00e9ponse restent stables. Des tests de charge r\u00e9p\u00e9t\u00e9s confirment si le nouveau <strong>Cadre<\/strong> m\u00eame en cas de pic de trafic. Sans chiffres, on ne fait que r\u00e9partir les sympt\u00f4mes au lieu de les traiter v\u00e9ritablement. <strong>Causes<\/strong> \u00e0 r\u00e9soudre.<\/p>\n\n<p>Pour obtenir des informations sur les applications, les outils de profilage et les journaux de requ\u00eates sont utiles, car ils r\u00e9v\u00e8lent les chemins co\u00fbteux. Je consigne s\u00e9par\u00e9ment les API externes afin de distinguer les services partenaires lents des probl\u00e8mes locaux. Si les d\u00e9lais d'attente surviennent principalement chez des fournisseurs tiers, j'augmente de mani\u00e8re s\u00e9lective la tol\u00e9rance ou je mets en place des disjoncteurs. Une s\u00e9paration claire acc\u00e9l\u00e8re l'analyse des erreurs et permet de se concentrer sur la partie ayant le plus grand effet de levier. Ainsi, la plateforme globale reste r\u00e9sistante aux incidents individuels. <strong>points faibles<\/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-limits-office-4837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>T\u00e2ches de longue dur\u00e9e : jobs, files d'attente et cron<\/h2>\n\n<p>Les t\u00e2ches telles que les exportations, les sauvegardes, les migrations et les piles d'images doivent \u00eatre effectu\u00e9es en arri\u00e8re-plan, et non dans la requ\u00eate frontale. J'utilise des scripts CLI ou des workers de file d'attente avec une <strong>Dur\u00e9e de validit\u00e9<\/strong> et des limites distinctes afin de lib\u00e9rer les interfaces. Je planifie les t\u00e2ches cron pendant les p\u00e9riodes creuses afin qu'elles n'interf\u00e8rent pas avec le trafic en direct. Pour la tol\u00e9rance aux erreurs, j'int\u00e8gre des strat\u00e9gies de r\u00e9essai avec backoff au lieu d'utiliser des r\u00e9p\u00e9titions fixes rigides. Ainsi, les t\u00e2ches longues s'ex\u00e9cutent de mani\u00e8re fiable sans perturber les flux d'utilisateurs. <strong>d\u00e9ranger<\/strong>.<\/p>\n\n<p>Si une t\u00e2che finit tout de m\u00eame par atterrir dans le contexte Web, je mise sur des r\u00e9ponses en streaming et la mise en cache des r\u00e9sultats interm\u00e9diaires. Les indicateurs de progression et le traitement partiel par lots \u00e9vitent les blocages prolong\u00e9s. Si la situation devient tout de m\u00eame critique, j'augmente temporairement le nombre de travailleurs, puis je le ram\u00e8ne \u00e0 son niveau normal. Cette \u00e9lasticit\u00e9 permet de calculer les co\u00fbts et d'\u00e9conomiser les ressources. Il reste essentiel de garder les chemins critiques courts et d'\u00e9liminer les ex\u00e9cutions lourdes du parcours utilisateur. <strong>d\u00e9placer<\/strong>.<\/p>\n\n<h2>Aspects li\u00e9s \u00e0 la s\u00e9curit\u00e9 et tol\u00e9rance aux erreurs dans le cas de limites \u00e9lev\u00e9es<\/h2>\n\n<p>Des valeurs d'ex\u00e9cution plus \u00e9lev\u00e9es prolongent la fen\u00eatre dans laquelle le code d\u00e9fectueux lie les ressources. Je s\u00e9curise cela par des <strong>interruptions<\/strong> dans le code, la validation des entr\u00e9es et les limites pour les appels externes. La limitation du d\u00e9bit sur les entr\u00e9es API emp\u00eache les inondations de processus longs par des bots ou les abus. C\u00f4t\u00e9 serveur, je fixe des limites strictes en mati\u00e8re de processus et de m\u00e9moire afin d'arr\u00eater les processus incontr\u00f4lables. Un concept de protection \u00e0 plusieurs niveaux r\u00e9duit les dommages, m\u00eame si un seul <strong>Demande<\/strong> d\u00e9raill\u00e9.<\/p>\n\n<p>Je con\u00e7ois des pages d'erreur informatives et concises afin que les utilisateurs voient des mesures utiles plut\u00f4t que des messages cryptiques. J'enregistre les journaux de mani\u00e8re structur\u00e9e et je les fais tourner afin d'\u00e9conomiser de l'espace disque. Je lie les alertes \u00e0 des seuils qui signalent les vrais probl\u00e8mes, et non chaque petit d\u00e9tail. Ainsi, l'\u00e9quipe r\u00e9agit rapidement aux incidents r\u00e9els et reste op\u00e9rationnelle en cas de dysfonctionnements. Une bonne observabilit\u00e9 r\u00e9duit le temps n\u00e9cessaire pour <strong>Cause<\/strong> drastique.<\/p>\n\n<h2>Erreurs fr\u00e9quentes concernant les limites<\/h2>\n\n<p>\u201e Plus c'est haut, mieux c'est \u201c n'est pas vrai, car des scripts trop longs bloquent la plateforme. \u201e Tout est une question de CPU \u201c est une vision trop r\u00e9ductrice, car la RAM, les E\/S et les services externes donnent le ton. \u201e OPcache suffit \u201c n\u00e9glige le fait que la latence de la base de donn\u00e9es et le r\u00e9seau comptent \u00e9galement. \u201e Optimiser uniquement le code \u201c ignore que la configuration et l'h\u00e9bergement ont le m\u00eame effet. Je combine la refonte du code, la mise en cache et <strong>Configuration<\/strong>, plut\u00f4t que de miser sur un levier.<\/p>\n\n<p>Une autre erreur de raisonnement : \u201e Timeout signifie serveur d\u00e9fectueux \u201c. En r\u00e9alit\u00e9, cela signale g\u00e9n\u00e9ralement des limites inappropri\u00e9es ou des chemins malheureux. En lisant les journaux, on reconna\u00eet les sch\u00e9mas et on corrige les endroits appropri\u00e9s. Le taux d'erreur diminue alors sans avoir \u00e0 remplacer le mat\u00e9riel. Un diagnostic clair permet d'\u00e9conomiser <strong>Budget<\/strong> et acc\u00e9l\u00e8re les r\u00e9sultats visibles.<\/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_workstation_limit_8231.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemples de configurations et benchmarks : ce qui fonctionne dans la pratique<\/h2>\n\n<p>Je m'appuie sur des profils de charge types et je les compare avec le budget RAM et le parall\u00e9lisme. Le tableau suivant r\u00e9capitule les combinaisons courantes et montre leur impact sur le temps de r\u00e9ponse et la stabilit\u00e9. Les valeurs servent de point de d\u00e9part et doivent \u00eatre adapt\u00e9es au trafic, \u00e0 la base de code et aux services externes. Apr\u00e8s le d\u00e9ploiement, je v\u00e9rifie les m\u00e9triques et continue \u00e0 les affiner par petites \u00e9tapes. Ainsi, le syst\u00e8me reste <strong>planifiable<\/strong> et n'est pas sensible aux arbre de transmission.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Sc\u00e9nario d'intervention<\/th>\n      <th>Temps d'ex\u00e9cution<\/th>\n      <th>Limite de m\u00e9moire<\/th>\n      <th>Effet escompt\u00e9<\/th>\n      <th>Risque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Petite page WP, peu de plugins<\/td>\n      <td>60 \u00e0 120 s<\/td>\n      <td>128 \u00e0 256 Mo<\/td>\n      <td>Mises \u00e0 jour stables, d\u00e9lais d'attente rares<\/td>\n      <td>Pics chez Media-Jobs<\/td>\n    <\/tr>\n    <tr>\n      <td>Blog\/Entreprise avec Page Builder<\/td>\n      <td>180 \u00e0 300 s<\/td>\n      <td>256 \u00e0 512 Mo<\/td>\n      <td>Temps de r\u00e9ponse r\u00e9duit de moiti\u00e9, moins d'interruptions<\/td>\n      <td>Longues courses avec une mauvaise DB<\/td>\n    <\/tr>\n    <tr>\n      <td>WooCommerce\/Boutique<\/td>\n      <td>300 s<\/td>\n      <td>512 MO<\/td>\n      <td>Importations, sauvegardes et flux stables<\/td>\n      <td>RAM \u00e9lev\u00e9e par travailleur<\/td>\n    <\/tr>\n    <tr>\n      <td>API\/Backends headless<\/td>\n      <td>30 \u00e0 120 s<\/td>\n      <td>256 \u00e0 512 Mo<\/td>\n      <td>Latence tr\u00e8s courte avec OPcache<\/td>\n      <td>D\u00e9lais d'attente pour les partenaires lents<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Si vous recevez beaucoup de requ\u00eates simultan\u00e9es, vous devriez \u00e9galement ajuster le pool PHP-FPM et le surveiller r\u00e9guli\u00e8rement. Une augmentation du nombre de workers sans \u00e9quivalent RAM aggrave le goulot d'\u00e9tranglement. Des processus \u00e9conomes avec OPcache et cache objet am\u00e9liorent le d\u00e9bit par c\u0153ur. En r\u00e9sum\u00e9, c'est l'\u00e9quilibre qui compte, et non les valeurs maximales sur un seul r\u00e9gulateur. C'est pr\u00e9cis\u00e9ment l\u00e0 que la structure porte ses fruits. <strong>Tuning<\/strong> de.<\/p>\n\n<h2>Limites associ\u00e9es : max_input_time, request_terminate_timeout et d\u00e9lais d'attente en amont<\/h2>\n\n<p>Outre max_execution_time, plusieurs voisins jouent \u00e9galement un r\u00f4le : <strong>max_input_time<\/strong> limite le temps dont dispose PHP pour analyser les entr\u00e9es (POST, t\u00e9l\u00e9chargements). Si cette limite est trop basse, les formulaires ou t\u00e9l\u00e9chargements volumineux \u00e9chouent avant m\u00eame que le code proprement dit ne d\u00e9marre, ind\u00e9pendamment du temps d'ex\u00e9cution. Au niveau FPM, cela met fin \u00e0 l'ex\u00e9cution. <strong>request_terminate_timeout<\/strong> les requ\u00eates trop longues, m\u00eame si PHP n'a pas encore atteint sa limite d'ex\u00e9cution. Les serveurs Web et les proxys fixent leurs propres limites : Nginx (proxy_read_timeout\/fastcgi_read_timeout), Apache (Timeout\/ProxyTimeout) et les \u00e9quilibreurs de charge\/CDN interrompent les r\u00e9ponses apr\u00e8s un d\u00e9lai d'attente d\u00e9fini. En pratique, la r\u00e8gle suivante s'applique : le <em>plus petit<\/em> gagne gr\u00e2ce \u00e0 un d\u00e9lai d'attente efficace. Je maintiens cette cha\u00eene coh\u00e9rente afin qu'aucune barri\u00e8re ext\u00e9rieure invisible ne fausse le diagnostic.<\/p>\n\n<p>Les services externes sont particuli\u00e8rement d\u00e9licats : si une requ\u00eate PHP attend une API, ce n'est pas seulement le temps d'ex\u00e9cution qui d\u00e9termine le r\u00e9sultat, mais aussi la configuration du client HTTP (d\u00e9lais de connexion\/lecture). Si vous ne fixez pas de d\u00e9lais clairs, vous occupez inutilement les travailleurs pendant trop longtemps. Je d\u00e9finis donc des d\u00e9lais de connexion et de r\u00e9ponse courts pour chaque int\u00e9gration et s\u00e9curise les chemins critiques avec une politique de r\u00e9essai et un disjoncteur.<\/p>\n\n<h2>CLI vs Web : des r\u00e8gles diff\u00e9rentes pour les t\u00e2ches en arri\u00e8re-plan<\/h2>\n\n<p>Les processus CLI se comportent diff\u00e9remment des FPM : par d\u00e9faut, la <strong>max_execution_time<\/strong> est souvent r\u00e9gl\u00e9 sur 0 (illimit\u00e9) dans le CLI, le <strong>memory_limit<\/strong> reste toutefois valable. Pour les importations, sauvegardes ou migrations longues, je choisis d\u00e9lib\u00e9r\u00e9ment l'interface CLI et d\u00e9finis des limites \u00e0 l'aide de param\u00e8tres :<\/p>\n\n<pre><code>php -d max_execution_time=0 -d memory_limit=512M bin\/job.php\n<\/code><\/pre>\n\n<p>C'est ainsi que je d\u00e9couple la charge d'ex\u00e9cution des requ\u00eates frontales. Dans WordPress, je pr\u00e9f\u00e8re traiter les t\u00e2ches lourdes via WP-CLI et ne laisser Web-Cron d\u00e9clencher que des t\u00e2ches courtes et red\u00e9marrables.<\/p>\n\n<h2>Ce que le code peut contr\u00f4ler lui-m\u00eame : set_time_limit, ini_set et les interruptions<\/h2>\n\n<p>Les applications peuvent supprimer certaines limites dans le cadre des sp\u00e9cifications du serveur : <strong>set_time_limit()<\/strong> et <strong>ini_set(\u201a max_execution_time \u2018)<\/strong> fonctionnent par requ\u00eate. Cela ne fonctionne que si les fonctions n'ont pas \u00e9t\u00e9 d\u00e9sactiv\u00e9es et qu'aucun d\u00e9lai d'expiration FPM inf\u00e9rieur n'est appliqu\u00e9. Je d\u00e9finis \u00e9galement des crit\u00e8res d'interruption explicites dans les boucles, je v\u00e9rifie la progression et j'enregistre les \u00e9tapes. <strong>ignore_user_abort(true)<\/strong> Permet de terminer les t\u00e2ches malgr\u00e9 une connexion client interrompue, ce qui est utile pour les exportations ou les webhooks. Sans arr\u00eats nets, ces passe-droits compromettent toutefois la stabilit\u00e9 ; ils restent donc l'exception, avec des gardes claires.<\/p>\n\n<h2>Planification des capacit\u00e9s : pm.max_children calculer au lieu de deviner<\/h2>\n\n<p>Au lieu d'augmenter aveugl\u00e9ment pm.max_children, je calcule les besoins r\u00e9els en m\u00e9moire. Pour cela, je mesure la moyenne <strong>RSS<\/strong> d'un processus FPM sous charge (par exemple via ps ou smem) et pr\u00e9voir une r\u00e9serve pour le noyau\/le cache de page. Une approximation simple :<\/p>\n\n<pre><code>RAM disponible pour PHP = RAM totale - base de donn\u00e9es - serveur web - r\u00e9serve OS pm.max_children \u2248 floor(RAM disponible pour PHP \/ \u00d8_RSS_par_processus PHP)\n<\/code><\/pre>\n\n<p>Important : <em>memory_limit<\/em> n'est pas une valeur RSS. Un processus avec une limite de 256 Mo occupe en r\u00e9alit\u00e9 entre 80 et 220 Mo, selon le flux de travail. Je proc\u00e8de donc \u00e0 un calibrage \u00e0 l'aide de mesures r\u00e9elles en pic. Si le \u00d8\u2011RSS est r\u00e9duit gr\u00e2ce \u00e0 la mise en cache et \u00e0 une extension moins lourde, davantage de travailleurs peuvent \u00eatre int\u00e9gr\u00e9s dans le m\u00eame budget RAM, ce qui s'av\u00e8re souvent plus efficace qu'une simple augmentation des limites.<\/p>\n\n<h2>D\u00e9pendances externes : d\u00e9finir d\u00e9lib\u00e9r\u00e9ment des d\u00e9lais d'attente<\/h2>\n\n<p>La plupart des requ\u00eates PHP \u201e en attente \u201c attendent une E\/S : base de donn\u00e9es, syst\u00e8me de fichiers, HTTP. Pour les bases de donn\u00e9es, je d\u00e9finis des limites de requ\u00eate, des strat\u00e9gies d'indexation et des cadres de transaction clairs. Pour les clients HTTP, je d\u00e9finis <strong>D\u00e9lais d'attente courts pour la connexion et la lecture<\/strong> et limite les tentatives \u00e0 quelques essais espac\u00e9s de mani\u00e8re exponentielle. Dans le code, je d\u00e9couple les appels externes en mettant les r\u00e9sultats en cache, en les parall\u00e9lisant (si possible) ou en les transf\u00e9rant vers des t\u00e2ches. Cela r\u00e9duit le risque qu'un seul partenaire lent bloque l'ensemble de la file d'attente FPM.<\/p>\n\n<h2>Batching et reprise : dompter les longues ex\u00e9cutions<\/h2>\n\n<p>Je d\u00e9compose les op\u00e9rations longues en \u00e9tapes clairement d\u00e9finies. <strong>lots<\/strong> (par exemple, 200 \u00e0 1 000 enregistrements par cycle) avec des points de contr\u00f4le. Cela r\u00e9duit la dur\u00e9e des requ\u00eates individuelles, facilite la reprise apr\u00e8s des erreurs et am\u00e9liore la visibilit\u00e9 de la progression. Composants pratiques :<\/p>\n\n<ul>\n  <li>Enregistrer de mani\u00e8re persistante le marqueur de progression (dernier ID\/derni\u00e8re page).<\/li>\n  <li>Op\u00e9rations idempotentes pour tol\u00e9rer les ex\u00e9cutions en double.<\/li>\n  <li>Contre-pression : r\u00e9duire dynamiquement la taille du lot lorsque le 95e centile augmente.<\/li>\n  <li>R\u00e9ponses en streaming ou \u00e9v\u00e9nements envoy\u00e9s par le serveur pour un retour en direct lors des t\u00e2ches d'administration.<\/li>\n<\/ul>\n\n<p>Associ\u00e9 \u00e0 OPcache et au cache d'objets, il permet d'obtenir des dur\u00e9es d'ex\u00e9cution stables et pr\u00e9visibles qui restent dans des limites r\u00e9alistes, au lieu d'augmenter globalement le temps d'ex\u00e9cution.<\/p>\n\n<h2>FPM\u2011Slowlog et visibilit\u00e9 en cas d'erreur<\/h2>\n\n<p>Pour une v\u00e9ritable compr\u00e9hension, j'active le <strong>FPM-Slowlog<\/strong> (request_slowlog_timeout, chemin d'acc\u00e8s slowlog). Si les requ\u00eates restent actives plus longtemps que le seuil, une trace arri\u00e8re est enregistr\u00e9e dans le journal, ce qui est tr\u00e8s utile en cas de blocages inexpliqu\u00e9s. En parall\u00e8le, le statut FPM (pm.status_path) fournit des chiffres en temps r\u00e9el sur les processus actifs\/inactifs, les files d'attente et la dur\u00e9e des requ\u00eates. Je corr\u00e8le ces donn\u00e9es avec les journaux d'acc\u00e8s (temps en amont, codes d'\u00e9tat) et les journaux lents de la base de donn\u00e9es afin d'identifier avec pr\u00e9cision le point le plus critique.<\/p>\n\n<h2>Conteneurs et VM : Cgroups et OOM en un coup d'\u0153il<\/h2>\n\n<p>Dans les conteneurs, l'orchestration limite le CPU et la RAM ind\u00e9pendamment du fichier php.ini. Si un processus s'ex\u00e9cute \u00e0 proximit\u00e9 du <strong>memory_limit<\/strong>, le noyau peut fermer le conteneur via OOM Killer malgr\u00e9 un param\u00e8tre PHP \u201e adapt\u00e9 \u201c. Je conserve donc une r\u00e9serve suppl\u00e9mentaire en dessous de la limite Cgroup, j'observe RSS au lieu de memory_limit uniquement et j'ajuste les tailles OPcache de mani\u00e8re conservatrice. Dans les environnements limit\u00e9s en termes de CPU, les dur\u00e9es d'ex\u00e9cution sont prolong\u00e9es \u2013 le m\u00eame temps d'ex\u00e9cution n'est alors souvent plus suffisant. Dans ce cas, le profilage et la r\u00e9duction cibl\u00e9e du parall\u00e9lisme sont plus utiles que des d\u00e9lais d'attente globalement plus longs.<\/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-server-performance-5742.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Versions PHP, JIT et extensions : petits r\u00e9glages, grands effets<\/h2>\n\n<p>Les versions r\u00e9centes de PHP apportent des optimisations notables du moteur. Le <strong>JIT<\/strong> acc\u00e9l\u00e8re rarement de mani\u00e8re spectaculaire les charges de travail Web typiques, contrairement \u00e0 OPcache qui le fait presque toujours. Je veille \u00e0 ce que les extensions restent l\u00e9g\u00e8res : chaque biblioth\u00e8que suppl\u00e9mentaire augmente l'empreinte m\u00e9moire et les co\u00fbts de d\u00e9marrage \u00e0 froid. J'ajuste realpath_cache_size et les param\u00e8tres OPcache (m\u00e9moire, strat\u00e9gie de revalidation) en fonction de la base de code. Ces d\u00e9tails r\u00e9duisent la part de CPU par requ\u00eate, ce qui, avec des limites de temps constantes, offre directement plus de marge.<\/p>\n\n<h2>Reconna\u00eetre les erreurs types : une petite liste de contr\u00f4le<\/h2>\n\n<ul>\n  <li>Beaucoup de 504\/502 sous charge : trop peu de travailleurs, service externe lent, d\u00e9lai d'expiration du proxy inf\u00e9rieur \u00e0 la limite PHP.<\/li>\n  <li>\u201e Maximum execution time exceeded \u201c dans le journal des erreurs : chemin d'acc\u00e8s au code\/requ\u00eate co\u00fbteux ou d\u00e9lai d'attente trop court \u2013 profilage et traitement par lots.<\/li>\n  <li>RAM instable, augmentation du swap : pm.max_children trop \u00e9lev\u00e9 ou \u00d8\u2011RSS sous-estim\u00e9.<\/li>\n  <li>D\u00e9lais d'attente r\u00e9guliers lors des t\u00e9l\u00e9chargements\/formulaires : harmoniser max_input_time\/post_max_size\/d\u00e9lais d'attente client.<\/li>\n  <li>Backend lent, frontend ok : cache objet\/OPcache trop petit ou d\u00e9sactiv\u00e9 dans les zones d'administration.<\/li>\n<\/ul>\n\n<h2>En bref<\/h2>\n\n<p>Les limites d'ex\u00e9cution PHP d\u00e9terminent la rapidit\u00e9 d'ex\u00e9cution des requ\u00eates et la fiabilit\u00e9 d'une page en cas de pics de trafic. Je d\u00e9finis le temps d'ex\u00e9cution et <strong>M\u00e9moire<\/strong> jamais isol\u00e9, mais adapt\u00e9 au CPU, au FPM-Worker et au caching. Pour WordPress et les boutiques en ligne, 300 secondes et 256-512 Mo constituent un bon point de d\u00e9part, compl\u00e9t\u00e9 par OPcache et le cache objet. Ensuite, j'ajuste en fonction du 95e centile, du taux d'erreur et de l'utilisation de la RAM jusqu'\u00e0 ce que les goulots d'\u00e9tranglement disparaissent. Cette m\u00e9thode permet de r\u00e9duire <strong>Timeouts<\/strong>, Le site reste r\u00e9actif et l'h\u00e9bergement reste pr\u00e9visible.<\/p>","protected":false},"excerpt":{"rendered":"<p>**Limites d'ex\u00e9cution PHP** expliqu\u00e9es : comment le **temps d'ex\u00e9cution PHP** et le **d\u00e9lai d'expiration du script** influencent les performances et optimisent le **r\u00e9glage de l'h\u00e9bergement**.<\/p>","protected":false},"author":1,"featured_media":16510,"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-16517","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":"1978","_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 Execution Limits","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":"16510","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16517","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=16517"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16517\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/16510"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=16517"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=16517"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=16517"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}