{"id":18921,"date":"2026-04-11T08:37:18","date_gmt":"2026-04-11T06:37:18","guid":{"rendered":"https:\/\/webhosting.de\/php-request-queueing-max-children-verarbeitungslimits-performance\/"},"modified":"2026-04-11T08:37:18","modified_gmt":"2026-04-11T06:37:18","slug":"php-request-queueing-max-children-processing-limits-performance","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/php-request-queueing-max-children-verarbeitungslimits-performance\/","title":{"rendered":"PHP-anmodningsk\u00f8 og behandlingsgr\u00e6nser: Optimal konfiguration for stabile servere"},"content":{"rendered":"<p>PHP-anmodningsk\u00f8er begr\u00e6nser, hvor mange anmodninger din server behandler p\u00e5 samme tid, og bestemmer derfor svartid, fejlrater og brugeroplevelse. Jeg vil vise dig, hvordan du <strong>Gr\u00e6nser for behandling<\/strong> og eliminere flaskehalse og opn\u00e5 ensartet levering gennem harmoniserede parametre.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>For at du kan komme i gang med det samme, vil jeg opsummere de vigtigste justeringsskruer til <strong>PHP-FPM<\/strong> sammen.<\/p>\n<ul>\n  <li><strong>pm.max_b\u00f8rn<\/strong>: Beregn den \u00f8vre gr\u00e6nse for samtidige PHP-processer, s\u00e5 de passer til RAM.<\/li>\n  <li><strong>listen.backlog<\/strong>: Maksimer kortvarig buffering af forbindelsesfors\u00f8g under spidsbelastninger.<\/li>\n  <li><strong>pm.max_anmodninger<\/strong>Genbrug processer regelm\u00e6ssigt for at undg\u00e5 hukommelsesl\u00e6kager og oppustethed.<\/li>\n  <li><strong>Timeouts<\/strong>: s\u00e6t request_terminate_timeout, max_execution_time og webserver timeouts konsekvent.<\/li>\n  <li><strong>Metrikker<\/strong>max b\u00f8rn n\u00e5et, tjek lyttek\u00f8en og slowlogs l\u00f8bende.<\/li>\n<\/ul>\n<p>Jeg fokuserer p\u00e5 klare n\u00f8gletal og m\u00e5lbare effekter, s\u00e5 enhver justering af <strong>Gr\u00e6nser<\/strong> forbliver sporbar. For hver \u00e6ndring overv\u00e5ger jeg logfiler og svartider, f\u00f8r jeg planl\u00e6gger det n\u00e6ste skridt og gradvist \u00f8ger eller mindsker v\u00e6rdierne. P\u00e5 den m\u00e5de forhindrer jeg bivirkninger som f.eks. memory swapping, som kan <strong>K\u00f8<\/strong> dramatisk l\u00e6ngere. Med denne tilgang bringer jeg spidsbelastninger under kontrol og holder svartiderne stabile. M\u00e5let er at opn\u00e5 en afbalanceret kapacitetsudnyttelse, der <strong>Ressourcer<\/strong> effektivt uden at overbelaste v\u00e6rten.<\/p>\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\/04\/serveroptimierung-php-req-queue-8453.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan fungerer PHP Request Queueing i PHP-FPM<\/h2>\n<p>Hver indg\u00e5ende HTTP-anmodning kr\u00e6ver sin egen <strong>Arbejder<\/strong>, og en worker betjener kun \u00e9n anmodning ad gangen. Hvis alle processer er optaget, ender yderligere opkald i <strong>K\u00f8<\/strong> og vente p\u00e5, at en proces bliver ledig. Hvis denne k\u00f8 vokser, stiger svartiderne, og fejl som 502\/504 forekommer hyppigere. Jeg er derfor opm\u00e6rksom p\u00e5 et fornuftigt forhold mellem antallet af processer og den tilg\u00e6ngelige hukommelse i stedet for blindt at fokusere p\u00e5 maksimal parallelitet. P\u00e5 den m\u00e5de opn\u00e5r jeg en konstant gennemstr\u00f8mningshastighed uden at <strong>RAM<\/strong> eller CPU'en bryder v\u00e6k.<\/p>\n\n<h2>V\u00e6lg processtyringstilstande rent<\/h2>\n<p>Ud over gr\u00e6nsev\u00e6rdierne er <strong>pm-tilstand<\/strong> reaktionsevne og ressourceforbrug:<\/p>\n<ul>\n  <li><strong>pm = dynamisk<\/strong>Jeg definerer start_servers, min_spare_servers og max_spare_servers. Denne tilstand er min standard for variable belastninger, fordi den reagerer hurtigt p\u00e5 stigninger og holder varme processer klar.<\/li>\n  <li><strong>pm = ondemand<\/strong>Processer oprettes kun, n\u00e5r det er n\u00f8dvendigt, og afsluttes efter process_idle_timeout. Det sparer RAM til sj\u00e6ldne adgange (admin, staging, cron endpoints), men kan f\u00f8re til tab af RAM i tilf\u00e6lde af pludselige spidsbelastninger. <strong>Koldstart<\/strong> og h\u00f8jere latenstid. Jeg bruger det derfor selektivt og med en gener\u00f8s backlog.<\/li>\n  <li><strong>pm = statisk<\/strong>: Et fast antal processer. Ideelt, hvis jeg har en <strong>h\u00e5rd \u00f8vre gr\u00e6nse<\/strong> og s\u00e6rligt forudsigelige ventetider (f.eks. L7-proxy foran nogle f\u00e5, men kritiske slutpunkter). RAM-kravet kan klart beregnes, men ubrugte processer binder hukommelsen.<\/li>\n<\/ul>\n<p>Jeg beslutter, hvilken tilstand der passer til profilen for hver pulje. Jeg bruger normalt dynamisk til frontends med varierende belastning, ondemand til utility-pools og statisk til dedikerede, latency-kritiske tjenester.<\/p>\n\n<h2>Bestem pm.max_children korrekt<\/h2>\n<p>Det vigtigste h\u00e5ndtag er <strong>pm.max_b\u00f8rn<\/strong>, fordi denne v\u00e6rdi definerer, hvor mange anmodninger der kan k\u00f8re samtidig. Jeg beregner startst\u00f8rrelsen ved hj\u00e6lp af tommelfingerreglen: (frit tilg\u00e6ngelig RAM - 2 GB reserve) divideret med den gennemsnitlige hukommelse per PHP-proces. Som en grov antagelse bruger jeg 40-80 MB pr. proces og starter med 200-300 processer p\u00e5 en 32 GB host. Under live-belastning \u00f8ger eller mindsker jeg gradvist og kontrollerer, om ventetiden p\u00e5 <strong>K\u00f8<\/strong> falder, og fejlraten bliver mindre. Hvis du vil dykke dybere ned, kan du finde baggrundsinformation om start- og gr\u00e6nsev\u00e6rdier p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/php-fpm-processtyring-pm-max-born-optimere-kerne\/\">Optimer pm.max_children<\/a>.<\/p>\n\n<h2>Koordiner start-, reserve- og backlog-v\u00e6rdier<\/h2>\n<p>Jeg s\u00e6tter <strong>pm.start_servers<\/strong> til omkring 15-30 procent af pm.max_children, s\u00e5 der er nok processer til r\u00e5dighed i starten, og der ikke er nogen koldstart. Med pm.min_spare_servers og pm.max_spare_servers definerer jeg et rimeligt vindue for frie processer, s\u00e5 nye foresp\u00f8rgsler ikke venter, og der samtidig ikke er un\u00f8dvendig tomgangstid, der binder hukommelsen. Listen.backlog er s\u00e6rlig vigtig: Denne kernebuffer rummer kortvarigt ekstra forbindelsesfors\u00f8g, n\u00e5r alle arbejdere har travlt. Ved spidsbelastninger s\u00e6tter jeg h\u00f8je v\u00e6rdier (f.eks. 65535), s\u00e5 <strong>k\u00f8<\/strong> ikke stopper f\u00f8r FPM-puljen. Mere dybdeg\u00e5ende baggrundsinformation om samspillet mellem webserveren, upstream og buffere kan findes i oversigten over <a href=\"https:\/\/webhosting.de\/da\/webserver-koing-latenstid-handtering-af-anmodninger-serverko\/\">K\u00f8 til webserver<\/a>.<\/p>\n\n<h2>Begr\u00e6ns anmodningernes k\u00f8retid, og genbrug processerne<\/h2>\n<p>Jeg forhindrer snigende hukommelsesstigninger med <strong>pm.max_anmodninger<\/strong>, som genstarter alle processer efter X anmodninger. Uh\u00f8jtidelige applikationer k\u00f8rer ofte godt med 500-800, men hvis der er mistanke om hukommelsesl\u00e6kager, reducerer jeg til 100-200 og observerer effekten. Derudover indkapsler request_terminate_timeout outliers ved at afslutte ekstremt langvarige foresp\u00f8rgsler efter en fast tid. Konsistens er vigtig: Jeg holder PHP's max_execution_time og webserverens timeouts i samme korridor, s\u00e5 det ene lag ikke afsluttes tidligere end det andet. Dette samspil holder <strong>Arbejder<\/strong> fri og beskytter poolen mod overbelastning.<\/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\/04\/PHP_Server_Limits_Besprechung_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>G\u00f8r k\u00f8er synlige: Logfiler og metrikker<\/h2>\n<p>Jeg l\u00e6ser regelm\u00e6ssigt FPM-logfilerne og er opm\u00e6rksom p\u00e5 <strong>max antal b\u00f8rn n\u00e5et<\/strong>, fordi denne post indikerer, at den \u00f8vre gr\u00e6nse for processerne er n\u00e5et. Samtidig overv\u00e5ger jeg lyttek\u00f8en, som afsl\u00f8rer et stigende eftersl\u00e6b i inputbufferen. I kombination med request_slowlog_timeout f\u00e5r jeg stack traces for langsomme punkter i koden og kan isolere database- eller API-bremser. Jeg korrelerer upstream_response_time fra webserverloggene med request_time og statuskoder for at indsn\u00e6vre kilden til lange svartider. Dette giver mig mulighed for at genkende, om flaskehalsen i PHP-FPM, den <strong>Database<\/strong> eller upstream-netv\u00e6rket.<\/p>\n\n<h2>Profiler for arbejdsbelastning: CPU-bundet vs. IO-bundet<\/h2>\n<p>For CPU-tunge processer skalerer jeg <strong>Parallelisme<\/strong> Jeg er forsigtig og orienterer mig n\u00f8je efter vCPU-nummeret, fordi yderligere processer n\u00e6ppe giver noget throughput. Hvis det hovedsageligt er en IO-belastning med databaseadgang eller eksterne API'er, kan jeg tillade flere processer, s\u00e5 l\u00e6nge RAM-budgettet er tilstr\u00e6kkeligt. E-handelskasser har gavn af l\u00e6ngere timeouts (f.eks. 300 s) for at kunne gennemf\u00f8re betalingsmetoder uden annulleringer. Jeg opfanger lynsalg ved at s\u00e6tte listen.backlog h\u00f8jt og \u00f8ge reservevinduet. Oplysninger om balancen mellem antallet af processer og v\u00e6rtens ydeevne er samlet i vejledningen til <a href=\"https:\/\/webhosting.de\/da\/php-workers-hosting-flaskehals-guide-balance\/\">PHP-Workers som flaskehals<\/a>.<\/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\/04\/php-request-queue-servers-6591.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Eksempel p\u00e5 beregninger og dimensionering<\/h2>\n<p>Jeg beregner f\u00f8rst hukommelsen pr. proces og udleder derefter en fornuftig <strong>\u00d8vre gr\u00e6nse<\/strong> af. Derefter tester jeg under reel belastning og observerer, om k\u00f8en bliver mindre, og om gennemstr\u00f8mningen stiger. Konservative startv\u00e6rdier reducerer risikoen for swapping og holder svartiden j\u00e6vn. Jeg forfiner derefter i sm\u00e5 trin for at v\u00e6re sikker p\u00e5 at bem\u00e6rke eventuelle bivirkninger. F\u00f8lgende tabel giver vejledning om startv\u00e6rdier og effekter p\u00e5 <strong>K\u00f8<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Parametre<\/th>\n      <th>Effekt<\/th>\n      <th>Startv\u00e6rdi (eksempel)<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>pm.max_b\u00f8rn<\/td>\n      <td>Maks. samtidig <strong>Processer<\/strong><\/td>\n      <td>200-300 (med 32 GB)<\/td>\n      <td>Sammenlign med RAM-budget og processt\u00f8rrelse<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.start_servers<\/td>\n      <td>Oprindeligt antal arbejdere<\/td>\n      <td>15-30 % fra max_b\u00f8rn<\/td>\n      <td>Undg\u00e5 koldstart, men hold tomgang p\u00e5 et minimum<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.min_spare_servers<\/td>\n      <td>Gratis <strong>Arbejder<\/strong> Minimum<\/td>\n      <td>z. B. 20<\/td>\n      <td>Direkte inddragelse af nye anmodninger<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_spare_servere<\/td>\n      <td>Maksimum for frie arbejdere<\/td>\n      <td>z. B. 40<\/td>\n      <td>Begr\u00e6ns RAM-forbruget af inaktive processer<\/td>\n    <\/tr>\n    <tr>\n      <td>listen.backlog<\/td>\n      <td>Kernel-buffer til forbindelsesfors\u00f8g<\/td>\n      <td>65535<\/td>\n      <td>D\u00e6mp spidsbelastninger og reducer afbrydelser i forbindelsen<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_anmodninger<\/td>\n      <td>genanvendelse <strong>Interval<\/strong><\/td>\n      <td>500-800, med l\u00e6kager 100-200<\/td>\n      <td>Minim\u00e9r m\u00e6ngden af hukommelse og h\u00e6ngepartier<\/td>\n    <\/tr>\n    <tr>\n      <td>request_terminate_timeout<\/td>\n      <td>H\u00e5rd anmodningsgr\u00e6nse<\/td>\n      <td>300-600 s<\/td>\n      <td>I overensstemmelse med timeouts for PHP og webservere<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Praktiske skabeloner til PHP FPM-pools<\/h2>\n<p>For en butik med mange l\u00e6seadgange s\u00e6tter jeg moderat <strong>Tal for processen<\/strong> og \u00f8g reservevinduet, s\u00e5 anmodninger ikke s\u00e6ttes i k\u00f8. For indholdssider med caching er det ofte tilstr\u00e6kkeligt med betydeligt f\u00e6rre arbejdere, s\u00e5 l\u00e6nge NGINX eller Apache leverer statisk indhold effektivt. Jeg adskiller multi-pool-ops\u00e6tninger i henhold til applikationsdele, der har forskellige hukommelsesprofiler, s\u00e5 ingen tung pool fortr\u00e6nger de andre. Jeg definerer separate puljer med deres egne timeout-regler for cron- eller k\u00f8arbejdere. S\u00e5dan holder jeg den interaktive <strong>Trafik<\/strong> gratis og bremser ikke nogen brugerhandlinger.<\/p>\n\n<h2>Webserver-timeouts, upstream og sockets<\/h2>\n<p>Jeg betragter FastCGI og proxy-timeouts fra <strong>Nginx<\/strong> eller Apache i samme vindue som FPM's timeouts, s\u00e5 intet lag afsluttes for tidligt. Jeg foretr\u00e6kker Unix-sockets frem for TCP, hvis begge tjenester k\u00f8rer p\u00e5 den samme v\u00e6rt, fordi ventetiden forbliver minimal. Til distribuerede ops\u00e6tninger bruger jeg TCP med stabile keepalive-v\u00e6rdier og en tilstr\u00e6kkelig stor forbindelsespulje. Ved h\u00f8j parallelitet synkroniserer nginx worker_connections og FPM's backlog-v\u00e6rdier. Det sikrer, at omdirigeringer forbliver hurtige, og jeg undg\u00e5r inaktiv tid p\u00e5 grund af for t\u00e6tte forbindelser. <strong>Opstr\u00f8ms<\/strong>-begr\u00e6nsninger.<\/p>\n\n<h2>Caching, OPCache og database som l\u00f8ftestang<\/h2>\n<p>Jeg l\u00f8ser mange serverproblemer ved at reducere dyre operationer og minimere <strong>Svartid<\/strong> lavere. Jeg sl\u00e5r OPCache til, \u00f8ger hukommelsesgr\u00e6nsen for cachen fornuftigt og sikrer en h\u00f8j cache-hitrate. For at opn\u00e5 tilbagevendende resultater bruger jeg applikationscaching, s\u00e5 PHP-processer afsluttes hurtigere. P\u00e5 databasesiden optimerer jeg langsomme foresp\u00f8rgsler og aktiverer foresp\u00f8rgselscacher, der passer til det anvendte system. Hvert millisekund, der spares, reducerer belastningen p\u00e5 <strong>K\u00f8<\/strong> og \u00f8ger gennemstr\u00f8mningen pr. medarbejder.<\/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\/04\/php_server_setup_8943.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sikre n\u00f8dmekanismer og genstart<\/h2>\n<p>Jeg aktiverer <strong>emergency_restart_threshold<\/strong> og emergency_restart_interval, s\u00e5 FPM-masteren genstarter, hvis for mange b\u00f8rn g\u00e5r ned hurtigt efter hinanden. Denne kontrollerede genstart forhindrer k\u00e6dereaktioner og holder tjenesten tilg\u00e6ngelig. Samtidig s\u00e6tter jeg klare gr\u00e6nser for hukommelse og antallet af processer for at forhindre eskalering. Sundhedstjek p\u00e5 upstream-siden fjerner automatisk defekte backends fra puljen og reducerer fejlraten. Dette holder <strong>Tilg\u00e6ngelighed<\/strong> mens jeg unders\u00f8ger den egentlige \u00e5rsag.<\/p>\n\n<h2>Finjuster operativsystemets og systemd's gr\u00e6nser<\/h2>\n<p>S\u00e5 det <strong>listen.backlog<\/strong> faktisk tr\u00e6der i kraft, justerer jeg kernegr\u00e6nserne. OS-v\u00e6rdien net.core.somaxconn skal v\u00e6re mindst lige s\u00e5 h\u00f8j som den indstillede backlog, ellers afbryder systemet k\u00f8en. Jeg tjekker ogs\u00e5 antallet af tilladte filbeskrivelser: I FPM-poolen kan jeg indstille rlimit_files, p\u00e5 serviceniveau sikrer jeg LimitNOFILE (systemd) og p\u00e5 kerneniveau fs.file-max. Webserveren har brug for lignende reserver, s\u00e5 den ikke n\u00e5r sine gr\u00e6nser tidligere.<\/p>\n<p>For mere stabile ventetider reducerer jeg <strong>vm.swappiness<\/strong>, s\u00e5 kernen ikke fortr\u00e6nger aktivt brugte hukommelsessider for tidligt. I latency-kritiske ops\u00e6tninger deaktiverer jeg <strong>Gennemsigtige store sider<\/strong>, for at undg\u00e5 lange sidefejl. Hvis FPM k\u00f8rer via TCP, synkroniserer jeg ogs\u00e5 net.ipv4.tcp_max_syn_backlog og reuse\/keepalive-parametre. S\u00e5danne OS-detaljer virker uanselige, men de afg\u00f8r, om k\u00f8er <em>glat<\/em> udl\u00f8ber, eller om forbindelser allerede er afvist f\u00f8r FPM.<\/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\/04\/php_request_queue_8432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e5l modstandsdygtigt hukommelse pr. proces<\/h2>\n<p>I stedet for at lave generaliserede estimater m\u00e5ler jeg <strong>Reelt forbrug<\/strong> pr. medarbejder under reel belastning. Jeg bruger v\u00e6rkt\u00f8jer som ps, smem eller pmap, filtrerer efter php-fpm-b\u00f8rn og tager gennemsnittet af RSS-v\u00e6rdierne, mens foresp\u00f8rgslerne k\u00f8rer. Det er vigtigt at tage h\u00f8jde for den delte OPCache-brug: delt hukommelse t\u00e6lles ikke flere gange. Jeg udleder pm.max_children fra den gennemsnitlige v\u00e6rdi og planl\u00e6gger ogs\u00e5 en reserve, s\u00e5 maskinen ikke l\u00f8ber ind i en flaskehals, selv under spidsbelastninger. <strong>Byttehandel<\/strong> h\u00e6lder.<\/p>\n<p>Jeg gentager denne m\u00e5ling efter \u00e6ndringer i funktioner eller udgivelser. Nye funktioner, flere afh\u00e6ngigheder eller \u00e6ndringer i frameworks kan \u00f8ge fodaftrykket pr. proces betydeligt. Dette holder antallet af processer realistisk og k\u00f8en kort.<\/p>\n\n<h2>PHP FPM-status, ping og live-m\u00e5linger<\/h2>\n<p>For at f\u00e5 en hurtig vurdering af situationen aktiverer jeg <strong>pm.status_path<\/strong> og en <strong>Ping-slutpunkt<\/strong> (ping.path\/ping.response). Over dette kan jeg se n\u00f8gletal som accepteret conn, listen queue len, idle\/busy processer, max children reached og deres progression. Jeg l\u00e6ser disse v\u00e6rdier med j\u00e6vne mellemrum og s\u00e6tter t\u00e6rskelv\u00e6rdier: Hvis lyttek\u00f8en stiger permanent, \u00f8ger jeg enten antallet af processer eller fjerner \u00e5rsagen til de langsomme anmodninger. Hvis maks. antal n\u00e5ede b\u00f8rn stiger, mens inaktiviteten forbliver lav, er puljen for lille eller blokeret af <strong>lange l\u00f8bere<\/strong>.<\/p>\n<p>Jeg adskiller ogs\u00e5 pools med forskellige profiler, s\u00e5 spidsbelastninger p\u00e5 \u00e9t omr\u00e5de (f.eks. API-import) ikke tvinger den interaktive trafik i kn\u00e6. I diagnostiske tilf\u00e6lde \u00f8ger jeg midlertidigt log_level og lader slowloggen optage flere pr\u00f8ver, men reducerer den derefter igen for at holde I\/O-belastningen lav.<\/p>\n\n<h2>Uploads, buffering og store anmodninger<\/h2>\n<p>Store uploads kan binde medarbejderne un\u00f8digt op, hvis PHP f\u00f8rst skal l\u00e6se hele anmodningen. Jeg s\u00f8rger for, at webserveren <strong>Buffere<\/strong> (f.eks. fastcgi_request_buffering til NGINX), s\u00e5 FPM f\u00f8rst starter, n\u00e5r kroppen er f\u00e6rdig. Det betyder, at ingen arbejder blokerer under uploaden. Jeg bruger client_max_body_size, post_max_size og max_input_time til at kontrollere, hvor store og hvor lange foresp\u00f8rgsler der kan v\u00e6re, uden at det g\u00e5r ud over endpoints. Hvis der er filer imellem, tildeler jeg tilstr\u00e6kkelig hurtig midlertidig hukommelse (SSD) for at undg\u00e5 bufferstop.<\/p>\n<p>For slutpunkter med meget store m\u00e6ngder (f.eks. eksport\/import) definerer jeg dedikerede pools med deres egne timeouts og mindre parallelitet. Det efterlader standardarbejderne frie, og <strong>K\u00f8<\/strong> af de vigtige brugerhandlinger.<\/p>\n\n<h2>Databaseforbindelser og poolgr\u00e6nser<\/h2>\n<p>Selv den bedste FPM-indstilling er ubrugelig, hvis <strong>Database<\/strong> tidligere begr\u00e6nset. Jeg tilpasser det maksimale antal samtidige PHP-processer til den faktiske tilg\u00e6ngelige DB-kapacitet. For vedvarende forbindelser eller forbindelsespuljer s\u00f8rger jeg for, at summen af alle puljer er <em>under<\/em> max_connections forbliver. Hvis der er mange korte foresp\u00f8rgsler, hj\u00e6lper det at begr\u00e6nse PHP-paralleliteten moderat, s\u00e5 DB'en ikke g\u00e5r i st\u00e5 mellem tusindvis af sessioner.<\/p>\n<p>Langsomme transaktioner skaber hurtigt et eftersl\u00e6b i FPM-k\u00f8en. Jeg analyserer derfor ventetider p\u00e5 l\u00e5se, brug af indekser og foresp\u00f8rgselsplaner. Enhver reduktion i DB-k\u00f8retiden reducerer straks PHP<strong>Dokumentets varighed<\/strong> og reducerer k\u00f8ernes l\u00e6ngde.<\/p>\n\n<h2>Udgivelser og udrulninger uden spidsbelastning<\/h2>\n<p>N\u00e5r jeg udruller nye versioner, undg\u00e5r jeg kolde cacher og processtorme. Jeg bruger <strong>Genindl\u00e6sning<\/strong> i stedet for h\u00e5rde genstarter, s\u00e5 eksisterende worker-anmodninger afsluttes rent (bem\u00e6rk process_control_timeout). Jeg varmer OPCache op p\u00e5 et tidligt tidspunkt ved at k\u00f8re kritiske stier \u00e9n gang, f\u00f8r jeg skifter, eller ved at arbejde med preloading. Det forhindrer mange arbejdere i at parse klassefiler p\u00e5 samme tid, og <strong>Svartid<\/strong> stiger med stormskridt.<\/p>\n<p>Med bl\u00e5\/gr\u00f8nne eller canary-strategier \u00f8ger jeg gradvist belastningen og overv\u00e5ger statussiderne. F\u00f8rst n\u00e5r k\u00f8en, fejlraten og ventetiden forbliver stabil, \u00f8ger jeg andelen af trafik. Denne kontrollerede tilgang beskytter mod spidsbelastninger under implementeringen.<\/p>\n\n<h2>Container- og VM-specialiteter<\/h2>\n<p>I containere er den opfattede <strong>Samlet opbevaringsvolumen<\/strong> ofte lavere end v\u00e6rtens rapporter. Jeg tilpasser pm.max_children strengt til cgroup-gr\u00e6nsen og planl\u00e6gger en reserve mod OOM-killeren. Hukommelsesgr\u00e6nserne i PHP (memory_limit) og fodaftrykket pr. proces skal stemme overens, ellers er en enkelt afvigelse nok til at afslutte containeren.<\/p>\n<p>Hvis der ikke er noget swap i containeren, er der st\u00f8rre sandsynlighed for h\u00e5rde aflysninger. Derfor holder jeg processerne konservative, aktiverer genbrug og overv\u00e5ger RSS-toppene i produktionsbelastningen. Her er flere slanke pools ofte mere robuste end \u00e9n stor, monolitisk pool.<\/p>\n\n<h2>Kontrollerbar nedbrydning og modtryk<\/h2>\n<p>Hvis den <strong>K\u00f8<\/strong> Jeg er afh\u00e6ngig af kontrolleret nedbrydning: Jeg leverer bevidst 503 med retry after til ikke-kritiske endpoints i tilf\u00e6lde af overbelastning, reducerer dyre funktioner (f.eks. live-s\u00f8gninger) og begr\u00e6nser parallel adgang til hotspots. Det holder systemet responsivt, mens jeg afhj\u00e6lper \u00e5rsagen, i stedet for at alle brugere l\u00f8ber ind i timeouts.<\/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\/04\/php-serverraum-1635.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n<p>Jeg bringer <strong>PHP Request Queueing<\/strong> under kontrol ved smart at tilpasse antallet af samtidige processer til RAM-budgettet og typen af belastning. H\u00f8je backlog-v\u00e6rdier buffer toppe, timeouts p\u00e5 alle niveauer passer fint sammen, og genbrug fjerner snigende hukommelsesproblemer. Logfiler og m\u00e5linger viser mig, om k\u00f8en vokser, hvor foresp\u00f8rgsler sidder fast, og hvorn\u00e5r jeg skal stramme op. Med omhyggelige justeringer og m\u00e5lrettet caching reducerer jeg behandlingstiden pr. anmodning og \u00f8ger gennemstr\u00f8mningen. P\u00e5 denne m\u00e5de leverer serverne konsekvent og undg\u00e5r dyre <strong>Timeouts<\/strong> i hverdagen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Mastering PHP request queueing: optimer max children php og server queue handling. Guide med praktiske tips til stabil ydelse under belastning.<\/p>","protected":false},"author":1,"featured_media":18914,"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-18921","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":"403","_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 Request Queueing","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":"18914","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18921","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=18921"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18921\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/18914"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=18921"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=18921"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=18921"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}