{"id":17358,"date":"2026-02-05T11:52:30","date_gmt":"2026-02-05T10:52:30","guid":{"rendered":"https:\/\/webhosting.de\/wordpress-php-fpm-children-blockieren-optimierungstuning-serverperf\/"},"modified":"2026-02-05T11:52:30","modified_gmt":"2026-02-05T10:52:30","slug":"wordpress-php-fpm-children-block-optimering-tuning-serverperf","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/wordpress-php-fpm-children-blockieren-optimierungstuning-serverperf\/","title":{"rendered":"WordPress PHP-FPM B\u00f8rn: Forkerte v\u00e6rdier blokerer sider"},"content":{"rendered":"<p><strong>PHP-FPM B\u00f8rn<\/strong> afg\u00f8r i WordPress, om foresp\u00f8rgsler k\u00f8rer glat eller bliver h\u00e6ngende i k\u00f8en. Jeg vil vise dig, hvordan forkert <strong>pm.max_b\u00f8rn<\/strong>-v\u00e6rdier blokerer sider, optager RAM, og hvordan jeg beregner rene v\u00e6rdier.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>F\u00f8r jeg g\u00e5r i dybden, vil jeg kort opsummere de vigtigste budskaber:<\/p>\n<ul>\n  <li><strong>pm.max_b\u00f8rn<\/strong> bestemmer, hvor mange samtidige PHP-anmodninger, der k\u00f8rer.<\/li>\n  <li><strong>For lidt<\/strong> B\u00f8rn genererer k\u00f8er, 502\/504 og h\u00f8j TTFB.<\/li>\n  <li><strong>For meget<\/strong> f\u00f8rer til RAM-flaskehalse, swap og OOM-d\u00f8dsfald.<\/li>\n  <li><strong>Formel<\/strong>tilg\u00e6ngelig PHP RAM \/ processt\u00f8rrelse \u00d7 0,7-0,8.<\/li>\n  <li><strong>Iterativ<\/strong> Tuning med overv\u00e5gning giver den bedste ydelse p\u00e5 lang sigt.<\/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\/02\/wordpress-serverproblem-7193.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorfor blokerer forkerte PHP-FPM-b\u00f8rnesider<\/h2>\n\n<p>Hver dynamisk WordPress-anmodning kr\u00e6ver sin egen <strong>Arbejder<\/strong>, og det er netop disse processer, som poolen kontrollerer via pm.max_children. Hvis jeg s\u00e6tter v\u00e6rdien for lavt, hober foresp\u00f8rgslerne sig op i en k\u00f8, og <strong>TTFB<\/strong> stiger m\u00e6rkbart. Hvis jeg s\u00e6tter v\u00e6rdien for h\u00f8jt, bruger hver underordnet proces ekstra RAM, og serveren skifter til swap. Alt g\u00e5r langsommere i swap, indtil Apache eller Nginx rapporterer 502\/504, eller OOM-killeren afslutter processerne. Sundt throughput opn\u00e5s kun, n\u00e5r antallet af b\u00f8rn matcher det reelle RAM-budget og projektets belastning.<\/p>\n\n<h2>Formlen for pm.max_children i praksis<\/h2>\n\n<p>Jeg starter med den enkle formel: tilg\u00e6ngelig RAM til PHP divideret med den gennemsnitlige st\u00f8rrelse af en underordnet proces, ganget med en <strong>Sikkerhedsfaktor<\/strong> Jeg bestemmer RAM pr. proces med ps og RSS-kolonnen; for typiske WordPress-stakke er 50-250 MB ofte korrekt. P\u00e5 en 4 GB-server reserverer jeg hukommelse til Linux-, database- og cachetjenester og efterlader omkring 1,5-2 GB til <strong>PHP<\/strong> forblive. Hvis procesgennemsnittet f.eks. er 100 MB, er 2.000 \/ 100 \u00d7 0,75 = 15 b\u00f8rn. Dette tal fungerer som et udgangspunkt, som jeg forfiner i henhold til belastningsprofil, caching og plugin-mix.<\/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\/02\/wordpress_fpm_meeting_4287.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Startv\u00e6rdier for typiske WordPress-ops\u00e6tninger<\/h2>\n\n<p>For sm\u00e5 blogs med 2 GB RAM, 8 b\u00f8rn, pm = dynamic og en pm.max_requests p\u00e5 ca. <strong>800<\/strong>. Til mellemstore projekter med 4 GB RAM indstiller jeg 12 children, start_servers 4, min_spare_servers 4. Store shops med 8 GB RAM eller mere har gavn af 21-40 children; hvis belastningen er permanent h\u00f8j, kan pm = static sikre konstant gennemstr\u00f8mning. Derefter tjekker jeg forholdet mellem CPU-udnyttelse, RAM-udnyttelse og svartider for at foretage finjusteringer. Hvis du vil dykke dybere ned, kan du finde baggrundsinformation p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/wordpress-php-fpm-optimale-indstillinger-ydeevne-serverboost\/\">optimale PHP-FPM-indstillinger<\/a>.<\/p>\n\n<h2>M\u00e5ling af processer: S\u00e5dan bestemmes RAM-krav<\/h2>\n\n<p>Jeg bestemmer f\u00f8rst processernes live-st\u00f8rrelse, f\u00f8r jeg s\u00e6tter v\u00e6rdier, for krystalkugler hj\u00e6lper ikke her og koster penge. <strong>Str\u00f8m<\/strong>. Kommandoen ps -ylC php-fpm -sort:rss returnerer RSS-st\u00f8rrelserne, som jeg overv\u00e5ger i l\u00f8bet af et par minutter. Processer vokser ofte under opdateringer eller cron-jobs, og derfor inkluderer jeg spidsbelastninger i beregningen. Jeg bruger ogs\u00e5 htop og free -h til at tjekke RAM-reserverne og m\u00e6ngden af swap. Jeg bruger disse data til at bestemme et p\u00e5lideligt gennemsnit og v\u00e6lge en konservativ sikkerhedsfaktor.<\/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\/02\/wordpress-phpfpm-blockiert-9327.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Et overblik over vigtige parametre<\/h2>\n\n<p>Ud over pm.max_children bestemmer andre puljeindstillinger, hvor rent WordPress behandler anmodninger, og hvor godt det frig\u00f8r hukommelse, hvilket m\u00e6rkbart reducerer <strong>Stabilitet<\/strong> pm regulerer tilstanden: dynamic tilpasser antallet af processer til belastningen, static opretholder et fast antal. pm.max_requests forhindrer opbl\u00f8dning af hukommelsen ved at genstarte processer efter X anmodninger. request_terminate_timeout beskytter mod oph\u00e6ngning for\u00e5rsaget af defekte eller langsomme scripts. Med dette s\u00e6t d\u00e6kker jeg 90 procent af de virkelige praktiske tilf\u00e6lde.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametre<\/th>\n      <th>Funktion<\/th>\n      <th>WordPress-anbefaling<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>pm<\/td>\n      <td>Processtyringstilstand<\/td>\n      <td>dynamisk til variabel belastning; statisk til permanent h\u00f8j trafik<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_b\u00f8rn<\/td>\n      <td>Maksimalt antal samtidige arbejdere<\/td>\n      <td>Tilg\u00e6ngelig PHP RAM \/ processt\u00f8rrelse \u00d7 0,75<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_anmodninger<\/td>\n      <td>Genbrug af processer<\/td>\n      <td>300-1.000; snarere lavere med WooCommerce<\/td>\n    <\/tr>\n    <tr>\n      <td>request_terminate_timeout<\/td>\n      <td>Annullering af langvarige anmodninger<\/td>\n      <td>60-120 sekunder mod b\u00f8jler<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Dynamisk, ondemand eller statisk - hvilken tilstand er den rigtige for dig?<\/h2>\n<p>Jeg v\u00e6lger den tilstand, der passer til belastningsprofilen: <strong>dynamisk<\/strong> er min standard, fordi den fleksibelt tilpasser antallet af aktive processer og dermed sparer RAM, n\u00e5r der ikke sker s\u00e5 meget. <strong>statisk<\/strong> Jeg bruger det, n\u00e5r belastningen er konstant, og jeg har brug for h\u00e5rde forpligtelser med hensyn til ventetid og gennemstr\u00f8mning - for eksempel under kampagner eller salg. <strong>ondemand<\/strong> er velegnet til servere med lange inaktivitetsfaser: Processer oprettes kun, n\u00e5r det er n\u00f8dvendigt, og afsluttes igen efter inaktivitet. Afvejningen er koldstart; den f\u00f8rste anmodning pr. ny proces f\u00f8les langsommere. For ondemand s\u00e6tter jeg <em>pm.process_idle_timeout<\/em> rent (f.eks. 10-20s), med dynamisk holder jeg <em>start_servere<\/em>, <em>min_spare_servere<\/em> og <em>max_spare_servere<\/em> t\u00e6t, s\u00e5 bassinet hurtigt bliver stort, men ikke \u201epuster sig op\u201c.<\/p>\n\n<h2>Eksempel p\u00e5 konfiguration af din pool<\/h2>\n\n<p>P\u00e5 Debian\/Ubuntu er pool-filen normalt placeret under \/etc\/php\/8.x\/fpm\/pool.d\/www.conf, hvilket giver mig en klar <strong>Struktur<\/strong> til tilpasninger. Jeg s\u00e6tter pm til dynamisk, forankrer en realistisk v\u00e6rdi for pm.max_children og holder reserveserveren t\u00e6t. Jeg s\u00e6tter genbrug til 500 for at begr\u00e6nse l\u00e6kager og RAM-for\u00f8gelser tidligt i forl\u00f8bet. Efter hver \u00e6ndring tester jeg belastningen og fjerner flaskehalse, f\u00f8r jeg \u00f8ger v\u00e6rdierne yderligere. For baggrundsinformation om gr\u00e6nsev\u00e6rdier, se indsigten p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/php-fpm-processtyring-pm-max-born-optimere-kerne\/\">Optimer pm.max_children<\/a>.<\/p>\n\n<pre><code>pm = dynamisk\npm.max_children = 15\npm.start_servers = 4\npm.min_spare_servers = 4\npm.max_spare_servers = 8\npm.max_requests = 500\nrequest_terminate_timeout = 90s\n<\/code><\/pre>\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\/02\/wordpress_phpfpm_techoffice_9271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Flere bassiner, stikkontakter og ren isolering<\/h2>\n<p>For flere projekter eller klart adskilte roller (frontend vs. admin\/REST) ops\u00e6tter jeg <strong>separate puljer<\/strong> med sin egen bruger og socket. P\u00e5 den m\u00e5de begr\u00e6nser hver pool sine egne b\u00f8rn, og en afvigelse blokerer ikke for resten. P\u00e5 en host foretr\u00e6kker jeg <strong>Unix-sokler<\/strong> sammenlignet med TCP (listen = \/run\/php\/site.sock) - lavere latenstid, mindre overhead. Jeg bruger TCP mellem Nginx\/Apache og PHP-FPM p\u00e5 forskellige hosts\/containere. Jeg bruger <em>listen.ejer<\/em>, <em>listen.gruppe<\/em> og <em>listen.mode<\/em> konsekvent og om n\u00f8dvendigt h\u00e6ve <em>listen.backlog<\/em> s\u00e5 korte spidsbelastninger ikke resulterer i forbindelsesfejl. Med en dedikeret admin-pool kan jeg opn\u00e5 en strammere <em>request_terminate_timeout<\/em> drev og <em>pm.max_anmodninger<\/em> lavere uden at bremse den caching-st\u00e6rke frontend-pool.<\/p>\n\n<h2>Genkende symptomer og reagere korrekt<\/h2>\n\n<p>Hvis fejlloggen regelm\u00e6ssigt siger \u201eserver reached pm.max_children\u201c, begr\u00e6nser puljen antallet af b\u00f8rn. <strong>Parallelisme<\/strong> og jeg \u00f8ger den moderat. Hvis 502\/504 forekommer med h\u00f8j swap-udnyttelse p\u00e5 samme tid, nulstiller jeg pm.max_children og s\u00e6nker pm.max_requests. Hvis CPU'en stiger med lav RAM-udnyttelse, er det normalt foresp\u00f8rgsler eller PHP-logik, der blokerer; jeg optimerer databasen og cachelagringen. Hvis foresp\u00f8rgsler sidder fast, hj\u00e6lper en strengere request_terminate_timeout og loganalyse med tidsstempler. Jeg tjekker i\u00f8jnefaldende toppe i forhold til cronjobs, s\u00f8geindeks og administratorhandlinger.<\/p>\n\n<h2>FPM-status og slowlog: pr\u00e6cis diagnose<\/h2>\n<p>Jeg aktiverer <strong>Status<\/strong> per pulje (pm.status_path) og l\u00e6se n\u00f8gletal som f.eks. <em>aktive processer<\/em>, <em>max antal b\u00f8rn n\u00e5et<\/em>, <em>lyttek\u00f8<\/em> og <em>maks. lyttek\u00f8<\/em> af. En permanent voksende listek\u00f8 viser tydeligt: for f\u00e5 b\u00f8rn eller blokerende backends. Jeg har ogs\u00e5 sat <em>request_slowlog_timeout<\/em> (f.eks. 3-5s) og en <em>slowlog<\/em>-sti. Det er s\u00e5dan, jeg ser stakspor af anmodninger, der tr\u00e6kker ud - ofte eksterne HTTP-kald, komplekse WooCommerce-foresp\u00f8rgsler eller billedmanipulationer. Med <em>catch_workers_output<\/em> advarsler fra arbejderne opsamles i logfilerne. P\u00e5 baggrund af disse data beslutter jeg, om mere parallelisme hj\u00e6lper, eller om jeg skal l\u00f8se flaskehalse i koden\/DB'en.<\/p>\n\n<h2>Overv\u00e5gning: 3-5 dages ren evaluering<\/h2>\n\n<p>Efter tuning observerer jeg belastningstoppe over flere dage, fordi kortvarig <strong>udsving<\/strong> bedrager. Jeg logger RAM, swap, 502\/504, TTFB og antallet af aktive processer i FPM-status. Under 80 procent RAM-udnyttelse uden swap og uden k\u00f8er har jeg ret. Hvis der opst\u00e5r flaskehalse under handlinger som checkout, s\u00f8gning eller import, justerer jeg specifikt pm.max_children og pm.max_requests. Hvert trin udf\u00f8res i sm\u00e5 justeringer og med en ny m\u00e5ling.<\/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\/02\/wordpress_phpfpm_bugfix_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hukommelsesberegning i detaljer: RSS, PSS og delt hukommelse<\/h2>\n<p>Procesvariablen er vanskelig: <strong>RSS<\/strong> (Resident Set Size) indeholder ogs\u00e5 delte segmenter som OPcache og biblioteker. Jeg overvurderer derfor hurtigt RAM-forbruget, hvis jeg bare beregner \u201eRSS \u00d7 Children\u201c. Bedre er det at <strong>PSS<\/strong>-view (Proportional Set Size), som fordeler delt hukommelse retf\u00e6rdigt p\u00e5 tv\u00e6rs af processer - v\u00e6rkt\u00f8jer som smem hj\u00e6lper her. Beregningen omfatter <strong>OPcache<\/strong> (f.eks. 256 MB + strenge), <strong>APCu<\/strong> (f.eks. 64-128 MB) og masterprocessen. PHP <em>memory_limit<\/em> er ikke et gennemsnit, men den \u00f8vre gr\u00e6nse pr. anmodning; der kan forekomme individuelle toppe, men det er gennemsnitsv\u00e6rdien, der t\u00e6ller. Jeg planl\u00e6gger en buffer, s\u00e5 spidsbelastninger, udrulninger og cronjobs ikke straks udl\u00f8ser swaps, og lader <em>pm.max_anmodninger<\/em> for at begr\u00e6nse opbl\u00e6sning af hukommelsen.<\/p>\n\n<h2>Reducer WordPress-specifik belastning<\/h2>\n\n<p>Jeg reducerer f\u00f8rst PHP-belastningen, f\u00f8r jeg \u00f8ger antallet af b\u00f8rn yderligere, fordi en hurtigere cache-hitrate sparer realtid. <strong>RAM<\/strong>. Full-page caches reducerer drastisk PHP-anmodninger, hvilket skaber kapacitet til checkout, s\u00f8gning og administration. OPcache med memory_consumption p\u00e5 256 MB accelererer bytekode og aflaster poolen. I praksis holder jeg PHP memory_limit p\u00e5 256M, s\u00e5 individuelle plugins ikke sl\u00f8ver serveren. Mere indsigt i flaskehalse kan findes i guiden <a href=\"https:\/\/webhosting.de\/da\/php-workers-hosting-flaskehals-guide-balance\/\">PHP-Worker som flaskehals<\/a>.<\/p>\n\n<h2>Database- og cache-backends i balance<\/h2>\n<p>Hver PHP-arbejder genererer potentielt en <strong>Databaseforbindelse<\/strong>. Hvis jeg \u00f8ger pm.max_children, \u00f8ges den samtidige DB-belastning ogs\u00e5. Jeg tjekker derfor MySQL\/MariaDB: <em>max_forbindelser<\/em>, buffer (innodb_buffer_pool_size) og foresp\u00f8rgselsplanl\u00e6ggeren. Redis\/Memcached skal f\u00f8lge med parallelt. <em>maxclients<\/em>, hukommelsesgr\u00e6nse og ventetider. En WordPress-instans med 20 aktive b\u00f8rn kan nemt m\u00e6tte DB'en, hvis flere dyre foresp\u00f8rgsler k\u00f8rer parallelt. Det er derfor, jeg tuner DB'en (indekser, langsomme foresp\u00f8rgsler) og s\u00e6tter den til <strong>Vedvarende objekt-caches<\/strong>, f\u00f8r jeg frigiver flere b\u00f8rn. Det \u00f8ger gennemstr\u00f8mningen uden at overbelaste backend.<\/p>\n\n<h2>WooCommerce, Cron og Admin: s\u00e6rlige tilf\u00e6lde<\/h2>\n\n<p>Butikker genererer flere samtidige dynamiske foresp\u00f8rgsler, hvilket er grunden til, at jeg bruger noget <strong>Luft<\/strong> med pm.max_children. Samtidig har jeg en tendens til at s\u00e6nke pm.max_requests for l\u00f8bende at reducere opbl\u00f8dning af hukommelsen. For import og cronjobs planl\u00e6gger jeg ekstra budget eller udf\u00f8rer opgaver uden for spidsbelastningsperioder. Administratoromr\u00e5det f\u00e5r ofte spidsbelastninger med kort varsel; caching giver mindre beskyttelse her, s\u00e5 effektiv poolkontrol t\u00e6ller. Hvis der er tegn p\u00e5 k\u00f8er, \u00f8ger jeg i sm\u00e5 trin og overv\u00e5ger m\u00e5lingerne umiddelbart efter.<\/p>\n\n<h2>Containere, vCPU-kvoter og OOM-f\u00e6lder<\/h2>\n<p>I containere og VM'er er der fokus p\u00e5 <strong>effektiv<\/strong> RAM-gr\u00e6nse (cgroups), ikke p\u00e5 v\u00e6rten. Jeg beregner derfor pm.max_children ud fra den tildelte gr\u00e6nse og ikke ud fra \u201efree -h\u201c. Container OOMs er n\u00e5desl\u00f8se - kernen afslutter processer h\u00e5rdt. CPU-kvoter t\u00e6ller ogs\u00e5 med: Flere b\u00f8rn hj\u00e6lper ikke, hvis 1-2 vCPU'er begr\u00e6nser computertiden. Som en tommelfingerregel skalerer jeg IO-tunge WordPress-arbejdsbelastninger til omkring 2-4\u00d7 antallet af vCPU'er; over dette \u00f8ges kontekstskift, men ikke den reelle gennemstr\u00f8mning. I orkestrerede milj\u00f8er udruller jeg \u00e6ndringer konservativt, observerer pod-genstarter og holder \u00f8je med readiness\/liveness probes, s\u00e5 korte opvarmningsfaser af FPM ikke t\u00e6ller som fejl.<\/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\/02\/wordpress-server-techniker-7483.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fejlkilder, der ofte overses<\/h2>\n\n<p>Mange problemer stammer ikke fra poolen, men fra <strong>Plugins<\/strong>, der multiplicerer anmodninger eller genererer lange processer. Indekserede s\u00f8gninger, brudte crawler-regler og overdrevne heartbeat-intervaller \u00f8ger belastningen. Derfor tjekker jeg altid logs, query monitor og caching-headers f\u00f8rst. Hvis belastningen kun forekommer med bestemte URL'er, tolker jeg det som en indikation p\u00e5 flaskehalse i plugins eller skabeloner. F\u00f8rst n\u00e5r disse problemer er l\u00f8st, skalerer jeg Children yderligere.<\/p>\n\n<h2>Forst\u00e5else af sessioner, admin AJAX og l\u00e5se<\/h2>\n<p>WordPress\/plugins arbejder delvist med <strong>Sessioner<\/strong>. Filbaserede sessionsl\u00e5se kan serialisere anmodninger - en enkelt langsom anmodning blokerer resten af det samme sessions-ID. Jeg holder sessionsforbruget nede og tjekker, om admin AJAX bursts (wp-admin\/admin-ajax.php) fyres af un\u00f8digt ofte. Heartbeat skal drosles fornuftigt ned, ellers genererer det belastning uden merv\u00e6rdi. Hvis der opst\u00e5r l\u00e5se eller lange filadgange, hj\u00e6lper det ikke med mere parallelitet; her hj\u00e6lper caching, hurtigere storage I\/O eller en anden sessionsh\u00e5ndtering. I logfiler genkender jeg s\u00e5danne m\u00f8nstre fra mange lignende foresp\u00f8rgsler, der starter p\u00e5 samme tid med us\u00e6dvanligt lange k\u00f8retider.<\/p>\n\n<h2>Et overblik over timeouts for Nginx, Apache og FastCGI<\/h2>\n\n<p>Webserveren s\u00e6tter ogs\u00e5 gr\u00e6nser, som jeg er n\u00f8dt til at harmonisere med FPM-v\u00e6rdierne, ellers g\u00e5r de i st\u00e5. <strong>Indstilling<\/strong>. Med Nginx er jeg opm\u00e6rksom p\u00e5 fastcgi_read_timeout og tilstr\u00e6kkeligt med arbejdsprocesser. Under Apache tjekker jeg mpm_event, keepalive-indstillinger og proxy-timeouts. Hvis disse gr\u00e6nser ikke er korrekte, rapporterer brugerne timeouts, selv om FPM stadig har kapacitet. Standardiserede tidsbudgetter holder stien fra klienten til PHP konsistent.<\/p>\n\n<h2>Udrulningsstrategi, test og drift<\/h2>\n<p>Jeg udruller \u00e6ndringer til pm.max_children trin for trin og tester dem under reel belastning. En genindl\u00e6sning af FPM (graceful) overtager konfigurationer uden at afbryde forbindelsen. F\u00f8r st\u00f8rre spring simulerer jeg spidsbelastninger (f.eks. salgsstart) og observerer <em>lyttek\u00f8<\/em>, CPU, RAM, 95.-99. percentil af latenstid og fejlrater. Jeg dokumenterer de antagelser, der er gjort, s\u00e5 senere teammedlemmer forst\u00e5r, hvorfor en v\u00e6rdi er valgt p\u00e5 denne m\u00e5de. Jeg indstiller alarmer for: swap &gt; 0, \u201emax children reached\u201c i status, stigende 502\/504 og DB-latency. Dette sikrer, at platformen forbliver stabil, selv m\u00e5neder senere, n\u00e5r trafikken og plugin-mixet \u00e6ndres.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Forkert indstillet <strong>PHP-FPM<\/strong>-b\u00f8rn g\u00f8r WordPress langsommere, enten i k\u00f8er eller i RAM-gr\u00e6nsen. Jeg bestemmer processt\u00f8rrelsen, reserverer hukommelse til systemtjenester og s\u00e6tter pm.max_children med buffer. Derefter kontrollerer jeg pm.max_requests, request_terminate_timeout og tilstanden pm = dynamisk eller statisk i henhold til belastningsprofilen. Caching, OPcache og rene plugins reducerer m\u00e6rkbart antallet af PHP-anmodninger. Hvis du implementerer disse trin konsekvent, vil du holde siderne responsive og serveren p\u00e5lidelig.<\/p>","protected":false},"excerpt":{"rendered":"<p>Forkerte **PHP-FPM-b\u00f8rn** blokerer WordPress-websteder. L\u00e6r php-fpm wordpress-tuning for perfekt wp php-b\u00f8rn og hosting-ydelse.<\/p>","protected":false},"author":1,"featured_media":17351,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-17358","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"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":"1398","_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":"1","_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-FPM Children","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":"17351","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/17358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=17358"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/17358\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/17351"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=17358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=17358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=17358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}