{"id":16181,"date":"2025-12-24T11:51:59","date_gmt":"2025-12-24T10:51:59","guid":{"rendered":"https:\/\/webhosting.de\/php-handler-vergleich-performance-hosting-optimus-cache\/"},"modified":"2025-12-24T11:51:59","modified_gmt":"2025-12-24T10:51:59","slug":"php-handler-sammenligning-ydeevne-hosting-optimus-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/php-handler-vergleich-performance-hosting-optimus-cache\/","title":{"rendered":"Sammenligning af PHP-handlere: Indvirkning p\u00e5 webhosting-ydeevne"},"content":{"rendered":"<p>Denne sammenligning af PHP-handlere viser, hvordan mod_php, CGI, FastCGI, PHP-FPM og LSAPI <strong>Ydelse<\/strong> p\u00e5 din hosting \u2013 fra CPU-belastning til tail-latens. Jeg forklarer konkret, hvilket valg der er bedst for WordPress, WooCommerce og trafikspidser. <strong>Opladningstid<\/strong> s\u00e6nker og samtidig sk\u00e5ner ressourcerne.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>PHP-FPM<\/strong> skaleres mere effektivt end mod_php og FastCGI.<\/li>\n  <li><strong>LSAPI<\/strong> leverer de bedste v\u00e6rdier p\u00e5 LiteSpeed.<\/li>\n  <li><strong>Isolering<\/strong> pr. bruger \u00f8ger sikkerheden.<\/li>\n  <li><strong>OPcache<\/strong> og Redis reducerer ventetider.<\/li>\n  <li><strong>P95\/P99<\/strong> viser \u00e6gte brugeroplevelser.<\/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\/2025\/12\/php-handler-serverraum-4731.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan fungerer PHP-handlere<\/h2>\n\n<p>En PHP-handler forbinder webserveren med fortolkeren og styrer <strong>Processer<\/strong>, hukommelse og I\/O for hver anmodning. CGI starter en ny proces for hver anmodning og indl\u00e6ser konfigurationer p\u00e5 ny, hvilket skaber overhead og <strong>Forsinkelse<\/strong> Forh\u00f8jet. Moderne varianter som FastCGI, PHP-FPM eller LSAPI holder arbejdere vedvarende klar og sparer dermed starttid, kontekstskift og CPU-cyklusser. OPcache forbliver i hukommelsen, hvilket betyder, at bytecode ikke skal kompileres hver gang, og dynamiske sider reagerer hurtigere. Samtidig bestemmer processtyringen, hvor mange samtidige anmodninger der m\u00e5 k\u00f8re, hvordan prioriteterne fasts\u00e6ttes, og hvordan belastningstoppe kan afb\u00f8des.<\/p>\n\n<h2>Direkte sammenligning af de mest almindelige forhandlere<\/h2>\n\n<p>Valget af handler bestemmer <strong>Skalering<\/strong>, sikkerhedsmodellen og RAM-behovet for en applikation. mod_php integrerer PHP i Apache-processen og leverer korte svartider, men lider under svag <strong>Isolering<\/strong> mellem konti. CGI adskiller brugerne tydeligt, men koster massiv CPU-tid pr. anmodning. FastCGI reducerer overhead, men er stadig mindre effektivt end et godt tunet PHP-FPM. LSAPI g\u00e5r endnu et skridt videre, n\u00e5r LiteSpeed er i brug, og stabiliserer is\u00e6r tail-latens ved mange samtidige forbindelser.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>handler<\/th>\n      <th>Ydelse<\/th>\n      <th>Sikkerhed<\/th>\n      <th>Krav til RAM<\/th>\n      <th>Skalerbarhed<\/th>\n      <th>Operationelt scenarie<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>mod_php<\/td>\n      <td>H\u00f8j<\/td>\n      <td>Lav<\/td>\n      <td>Lav<\/td>\n      <td>Medium<\/td>\n      <td>Sm\u00e5 steder, sj\u00e6ldne h\u00f8jdepunkter<\/td>\n    <\/tr>\n    <tr>\n      <td>CGI<\/td>\n      <td>Lav<\/td>\n      <td>H\u00f8j<\/td>\n      <td>H\u00f8j<\/td>\n      <td>Lav<\/td>\n      <td>Statisk indhold, test<\/td>\n    <\/tr>\n    <tr>\n      <td>FastCGI<\/td>\n      <td>Medium<\/td>\n      <td>Medium<\/td>\n      <td>Medium<\/td>\n      <td>Medium<\/td>\n      <td>midlertidig l\u00f8sning<\/td>\n    <\/tr>\n    <tr>\n      <td>PHP-FPM<\/td>\n      <td>Meget h\u00f8j<\/td>\n      <td>H\u00f8j<\/td>\n      <td>Lav<\/td>\n      <td>H\u00f8j<\/td>\n      <td>Delt hosting, CMS<\/td>\n    <\/tr>\n    <tr>\n      <td>LSAPI<\/td>\n      <td>H\u00f8jeste<\/td>\n      <td>Medium<\/td>\n      <td>Meget lav<\/td>\n      <td>Meget h\u00f8j<\/td>\n      <td>H\u00f8j trafik, e-handel<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phphandler_vergleich_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>PHP-FPM i praksis: Processer, puljer, tuning<\/h2>\n\n<p>PHP-FPM arbejder med worker-pools, der henter foresp\u00f8rgsler fra en k\u00f8 og dermed <strong>Belastningsspidser<\/strong> elegant afb\u00f8de. Jeg opretter en separat pool for hver hjemmeside, s\u00e5 konfiguration, begr\u00e6nsninger og brugerkontekst forbliver adskilt, og <strong>Sikkerhed<\/strong> stiger. I praksis betaler adaptive indstillinger som pm = dynamic eller ondemand sig, fordi antallet af aktive processer tilpasses eftersp\u00f8rgslen. Det er afg\u00f8rende at dimensionere pm.max_children og tidsgr\u00e6nserne korrekt, s\u00e5 k\u00f8en ikke vokser, og der stadig er RAM-reserver. Til at begynde med anbefaler jeg at kontrollere parametrene struktureret; detaljer om finjustering forklarer jeg her: <a href=\"https:\/\/webhosting.de\/da\/php-fpm-processtyring-pm-max-born-optimere-kerne\/\">PHP-FPM processtyring<\/a>.<\/p>\n\n<h2>LSAPI og LiteSpeed: Topv\u00e6rdi ved h\u00f8j samtidighed<\/h2>\n\n<p>LSAPI holder PHP-processer i hukommelsen og reducerer kontekstskift, hvilket g\u00f8r det muligt at levere dynamisk indhold med <strong>HTTP\/3<\/strong> og QUIC leveres endnu mere smidigt. Under fuld belastning forbliver P95\/P99-latensen mere stabil end hos mange alternativer, hvilket g\u00f8r <strong>Brugeroplevelse<\/strong> synligt forbedret. Jeg ser regelm\u00e6ssigt flere foresp\u00f8rgsler pr. sekund og kortere TTFB p\u00e5 shop- og indholdssider, is\u00e6r n\u00e5r OPcache og servercache arbejder sammen. Fordelen viser sig ikke kun i gennemsnitsv\u00e6rdier, men ogs\u00e5 ved samtidige sessioner, sessioner med cache-misses og \u201ekolde\u201c PHP-arbejdere. Hvis du vil forst\u00e5 forskellen i arkitekturen, kan du l\u00e6se oversigten over <a href=\"https:\/\/webhosting.de\/da\/litespeed-vs-nginx-arkitektur-ydeevne-forklaring-speedboost\/\">LiteSpeed vs. Nginx<\/a> og tr\u00e6ffer derefter en beslutning om stakken.<\/p>\n\n<h2>WordPress og WooCommerce: Korrekt klassificering af m\u00e5lev\u00e6rdier<\/h2>\n\n<p>Med WordPress opn\u00e5r jeg h\u00f8je resultater med PHP 8.2 p\u00e5 FPM eller LSAPI. <strong>req\/s<\/strong>-v\u00e6rdier, mens WooCommerce gennem sessioner, indk\u00f8bskurvlogik og flere databaseadgange klarer lidt f\u00e6rre anmodninger pr. sekund. Testen bliver f\u00f8rst meningsfuld under realistiske <strong>Trafik<\/strong> blandet med caching-hits og -misses. Kritisk CSS, objektcache og persistente forbindelser flytter gr\u00e6nsen for, hvorn\u00e5r der opst\u00e5r flaskehalse. Korte TTL'er for ofte \u00e6ndret indhold og differentierede cache-n\u00f8gler for sprog, brugerstatus og enhedstype er s\u00e6rligt nyttige. P\u00e5 den m\u00e5de forbliver siden hurtig, selvom den leverer personaliseret indhold.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/php-handler-vergleich-performance-4762.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sikkerhed og isolation: Pools, brugerkontekst, begr\u00e6nsninger<\/h2>\n\n<p>Jeg foretr\u00e6kker separate servere til multi-user-hosting. <strong>Pools<\/strong> pr. konto, s\u00e5 rettigheder, stier og begr\u00e6nsninger forbliver adskilt fra hinanden. mod_php deler en f\u00e6lles kontekst, hvilket g\u00f8r det <strong>Risiko<\/strong> \u00f8ges, hvis et projekt har huller. FPM eller LSAPI med brugerkonfigurationer reducerer denne s\u00e5rbarhed betydeligt, fordi processerne k\u00f8rer under den respektive bruger. Derudover er det muligt at indstille forskellige php.ini-indstillinger p\u00e5 projektniveau uden at p\u00e5virke andre websteder. Ressourcebegr\u00e6nsninger som max_execution_time og memory_limit pr. pool forhindrer, at afvigelser bremser serveren.<\/p>\n\n<h2>Ressourceforbrug og RAM-planl\u00e6gning<\/h2>\n\n<p>Hver PHP-worker bruger, afh\u00e6ngigt af kode, udvidelser og <strong>OPcache<\/strong>-St\u00f8rrelsen varierer betydeligt, hvorfor jeg m\u00e5ler den faktiske bel\u00e6gning i stedet for at g\u00e6tte. V\u00e6rkt\u00f8jer som ps, top eller systemd-cgtop viser, hvor meget RAM aktive arbejdere reelt bel\u00e6gger, og hvorn\u00e5r. <strong>Byttehandel<\/strong> truer. Derefter fasts\u00e6tter jeg pm.max_children konservativt, lader headroom til database, webserver og cache-tjenester og observerer P95-latensen under peak. Hvis der er reserver tilbage, \u00f8ger jeg antallet af b\u00f8rn gradvist og kontrollerer igen. P\u00e5 denne m\u00e5de vokser den samlede kapacitet kontrolleret uden at overbelaste serveren.<\/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\/2025\/12\/phphandlervergleich_nacht_3207.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e5lemetode: Fra TTFB til P99<\/h2>\n\n<p>Jeg vurderer ikke kun gennemsnitsv\u00e6rdier, men frem for alt <strong>P95<\/strong>\u2013 og P99-latenser, fordi de afspejler den reelle oplevelse under belastning. En stack kan fungere med identisk gennemstr\u00f8mning og alligevel virke d\u00e5rligere ved P99, hvis <strong>K\u00f8er<\/strong> vokse. Derfor tester jeg kolde og varme caches, blander l\u00e6se- og skriveforesp\u00f8rgsler og bruger realistiske samtidighedsv\u00e6rdier. Uden OPcache-opvarmning fortolker jeg resultaterne med forsigtighed, da mange systemer bliver betydeligt hurtigere efter f\u00e5 opvarmningskald. F\u00f8rst efter repr\u00e6sentative testk\u00f8rsler tr\u00e6ffer jeg beslutning om h\u00e5ndtering, cachingstrategi og procesgr\u00e6nser.<\/p>\n\n<h2>Beslutningsvejledning til valg af handler<\/h2>\n\n<p>For sm\u00e5 sider med f\u00e5 logins er mod_php eller et sparsomt <strong>FPM<\/strong>-Ops\u00e6tning, forudsat at sikkerhedsaspekterne er taget i betragtning. Hvis samtidigheden \u00f8ges, skifter jeg til <strong>PHP-FPM<\/strong> med separate pools pr. projekt og aktiverer OPcache konsekvent. Ved meget dynamiske butikker og mange sessioner foretr\u00e6kker jeg LiteSpeed med LSAPI for at holde P95 og P99 lave. Hvis man af pris- eller arkitekturm\u00e6ssige \u00e5rsager forbliver ved Apache\/Nginx, fungerer en n\u00f8je afstemt FPM meget godt. I alle tilf\u00e6lde t\u00e6ller m\u00e5linger under realistiske forhold mere end benchmarks p\u00e5 et tomt system.<\/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\/2025\/12\/php_handler_vergleich_4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praksisops\u00e6tning: Caching, sessioner, tidsbegr\u00e6nsninger<\/h2>\n\n<p>Jeg satser p\u00e5 OPcache med gener\u00f8s <strong>Hukommelse<\/strong>-Allokering, s\u00e5 bytecode sj\u00e6ldent fortr\u00e6nges, og flyt sessioner efter mulighed i <strong>Redis<\/strong>, for at undg\u00e5 fil-l\u00e5sninger. Dette reducerer ventetiden ved samtidige logins og personaliserede sider. For eksterne tjenester definerer jeg klare timeouts og circuit breakers, s\u00e5 nedbrud ikke blokerer hele anmodningen. P\u00e5 applikationsniveau holder jeg cache-TTL'er korte nok til at sikre aktualitet, men lange nok til at opn\u00e5 en h\u00f8j hit-ratio. Hvis du regelm\u00e6ssigt st\u00f8der p\u00e5 worker-begr\u00e6nsninger, kan du finde en introduktion her: <a href=\"https:\/\/webhosting.de\/da\/php-workers-hosting-flaskehals-guide-balance\/\">Balanc\u00e9r PHP-Worker korrekt<\/a>.<\/p>\n\n<h2>Omkostnings-nytte-sammenligning og drift<\/h2>\n\n<p>Jeg vurderer <strong>Omkostninger<\/strong> en \u00e6ndring mod den m\u00e5lbare gevinst i form af latenstid, gennemstr\u00f8mning og p\u00e5lidelighed. Overgangen fra FastCGI til PHP-FPM giver ofte mere end en \u00e6ndring af PHP-underversionens nummer, fordi <strong>Proces<\/strong>-Management og caching virker kontinuerligt. LSAPI er is\u00e6r v\u00e6rdifuldt, hvis LiteSpeed alligevel er i brug, og der er mange samtidige bes\u00f8gende. Hvis du \u00e6ndrer stakken, b\u00f8r du f\u00f8lge logfiler og m\u00e5linger n\u00f8je og forberede rollback-stier. En planlagt A\/B-drift over flere dage giver de mest p\u00e5lidelige resultater.<\/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\/2025\/12\/php-handler-vergleich-5763.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Webserver-samspil: Apache-MPM, Nginx og Keep-Alive<\/h2>\n\n<p>I praksis er det ikke kun PHP-handleren, der er afg\u00f8rende, men ogs\u00e5 webservermodus. mod_php fungerer med Apache i <strong>prefork<\/strong>-MPM, men blokerer brugen af moderne event-modeller. Hvis du vil betjene HTTP\/2, l\u00e6ngere keep-alive-faser og tusindvis af forbindelser effektivt, skal du satse p\u00e5 Apache. <strong>begivenhed<\/strong> + PHP-FPM eller p\u00e5 Nginx\/LiteSpeed som frontend. Konsekvensen: Antallet af n\u00f8dvendige PHP-arbejdere afh\u00e6nger ikke af antallet af TCP-forbindelser, men af de faktiske <em>p\u00e5 samme tid<\/em> l\u00f8bende PHP-anmodninger. HTTP\/2\/3-multiplexing reducerer s\u00e5ledes header-overhead p\u00e5 webserveren, men \u00e6ndrer ikke noget ved for sm\u00e5 PHP-puljer.<\/p>\n\n<p>Nginx videresender typisk foresp\u00f8rgsler via FastCGI til FPM. Jeg s\u00f8rger for, at <strong>read_timeout<\/strong>- og <strong>send_timeout<\/strong>-v\u00e6rdier p\u00e5 proxyen, ellers opst\u00e5r der 502\/504-fejl ved h\u00e6ngende upstreams, selvom PHP stadig fungerer. I Apache-milj\u00f8er begr\u00e6nser jeg Keep-Alive, s\u00e5 lange inaktive forbindelser ikke binder thread-poolen. LiteSpeed abstraherer meget af dette, men udnytter f\u00f8rst sin fordel fuldt ud med LSAPI.<\/p>\n\n<h2>OPcache, JIT og preloading: hvad der virkelig hj\u00e6lper<\/h2>\n\n<p>OPcache er obligatorisk. I praksis dimensionerer jeg <strong>opcache.memory_consumption<\/strong> gener\u00f8s (f.eks. 192\u2013512 MB afh\u00e6ngigt af kodebasen) og \u00f8g <strong>opcache.max_accelererede_filer<\/strong>, s\u00e5 der ikke opst\u00e5r evictions. For builds, der sj\u00e6ldent implementeres, deaktiverer jeg <strong>validere_tidsstempler<\/strong> eller s\u00e6t en h\u00f8jere <strong>revalidate_freq<\/strong>, for at spare syscalls. <strong>Forudindl\u00e6sning<\/strong> kan fremskynde rammer, men har is\u00e6r effekt ved en konsistent autoload-struktur. Det <strong>JIT<\/strong> fra PHP giver sj\u00e6ldent fordele ved klassiske web-workloads og kan endda koste RAM; jeg aktiverer det kun, hvis benchmarks under reelle forhold bekr\u00e6fter dette.<\/p>\n\n<h2>K\u00f8h\u00e5ndtering og modtryk<\/h2>\n\n<p>De fleste flaskehalse opst\u00e5r ikke i CPU'en, men i <strong>k\u00f8<\/strong>. Hvis der kommer flere anmodninger ind, end medarbejderne kan behandle, vokser k\u00f8en, og P95\/P99-latensen skyder i vejret. Jeg s\u00f8rger for, at <strong>pm.max_b\u00f8rn<\/strong> stor nok til at absorbere typiske spidsbelastninger, men lille nok til at bevare RAM-reserven. <strong>pm.max_anmodninger<\/strong> Jeg indstiller den moderat (f.eks. 500\u20132000), s\u00e5 hukommelsesl\u00e6kager ikke skaber langvarige processer. <strong>listen.backlog<\/strong> skal passe til webserverens backlog, ellers afbryder kernen forbindelser under belastning. Hvis man m\u00e5ler ankomstfrekvensen (anmodninger pr. sekund) og den gennemsnitlige servicetid, kan man ved hj\u00e6lp af en simpel kapacitetsberegning vurdere, ved hvilken samtidighed latenstiden \u00e6ndrer sig.<\/p>\n\n<h2>Timeouts, uploads og langdistancel\u00f8b<\/h2>\n\n<p>Lange uploads eller API-kald blokerer arbejdere. Jeg definerer klare gr\u00e6nser: <strong>max_udf\u00f8relsestid<\/strong> og <strong>request_terminate_timeout<\/strong> i FPM forhindrer, at defekte anmodninger k\u00f8rer i evigheder. P\u00e5 proxy-niveau synkroniserer jeg <strong>proxy_read_timeout<\/strong>\/<strong>fastcgi_read_timeout<\/strong> med FPM-gr\u00e6nserne, s\u00e5 der ikke opst\u00e5r for tidlige 504-fejl. Store uploads streamer jeg og begr\u00e6nser <strong>post_max_size<\/strong> og <strong>upload_max_filesize<\/strong> streng og planl\u00e6g dedikerede slutpunkter, s\u00e5 den resterende trafik ikke lider under det. For cron-lignende langdistancel\u00f8b flytter jeg arbejdet til <strong>Stikord<\/strong> eller CLI-opgaver i stedet for at blokere frontend-arbejdere i flere minutter.<\/p>\n\n<h2>Sessions og l\u00e5sning i detaljer<\/h2>\n\n<p>PHP-sessioner er som standard <strong>sp\u00e6rrende<\/strong>. En anden anmodning fra samme bruger venter, indtil den f\u00f8rste frigiver sessionen \u2013 hvilket er fatalt for WooCommerce, hvis der k\u00f8rer parallelle Ajax-kald. Jeg afslutter sessionens skriveadgang tidligt med <em>session_write_close()<\/em>, s\u00e5 snart der ikke l\u00e6ngere er behov for mutationer. Med Redis som session-backend falder I\/O-latensen, men l\u00e5se-reglerne forbliver vigtige. Bag load balancere v\u00e6lger jeg bevidst mellem sticky sessions (enkelt, mindre skalerbart) og stateless m\u00f8nstre med objektcache, s\u00e5 horisontal skalering fungerer optimalt.<\/p>\n\n<h2>Overv\u00e5gning og fejlfinding<\/h2>\n\n<p>Uden telemetri er tuning som at flyve i blinde. Jeg aktiverer FPM-status og slowlogs pr. pool for at se flaskehalse og identificere foresp\u00f8rgsler, der skiller sig ud.<\/p>\n\n<pre><code>; pr. pool pm.status_path = \/status ping.path = \/ping ping.response = pong request_slowlog_timeout = 3s slowlog = \/var\/log\/php-fpm\/www-slow.log pm.max_requests = 1000\n<\/code><\/pre>\n\n<p>Hvis der opst\u00e5r 502\/504-fejl, tjekker jeg f\u00f8rst: Er FPM-k\u00f8en fuld? Er der CPU-steal eller swap? Passer webserver-timeout med FPM-gr\u00e6nserne? Et kig i <em>smaps<\/em> pr. medarbejder viser den faktiske RSS-bel\u00e6gning, mens <em>netstat<\/em>\/<em>ss<\/em> Afsl\u00f8rer backlog-overskridelser. For OPcache overv\u00e5ger jeg hitfrekvensen og antallet af revalideringer for at undg\u00e5 evictions.<\/p>\n\n<h2>Containere, stik og ressourcebegr\u00e6nsninger<\/h2>\n\n<p>I containere bruger jeg oftest <strong>TCP<\/strong> i stedet for Unix-sockets mellem webserver og FPM for at undg\u00e5 navnerumsgr\u00e6nser og lette belastningsbalancering. Det er vigtigt med konsistente <strong>cgroup<\/strong>-Begr\u00e6nsninger: Hvis containeren kun har 1\u20132 GB RAM, skal pm.max_children v\u00e6re tilsvarende mindre, ellers tr\u00e6der OOM-killer i kraft. CPU-kvoter har stor indflydelse p\u00e5 reaktionstiden; jeg planl\u00e6gger headroom og verificerer P95-latensen under gr\u00e6nsen. NUMA- og Core-Affinity-emner bliver relevante ved meget h\u00f8j belastning, mens LSAPI i LiteSpeed-ops\u00e6tninger optimerer meget af dette internt.<\/p>\n\n<h2>Multi-PHP-versioner og udvidelser<\/h2>\n\n<p>Mange v\u00e6rter k\u00f8rer flere PHP-versioner parallelt. Jeg isolerer puljer pr. version og holder <strong>Udvidelser<\/strong> slank. Hvert ekstra modul \u00f8ger RAM pr. worker og kan forl\u00e6nge opstartstiden. Jeg fjerner konsekvent ubrugte udvidelser; det giver ofte mere end en mindre pm.max_children-for\u00f8gelse. Ved opgraderingen planl\u00e6gger jeg korte opvarmningsfaser for OPcache, s\u00e5 ikke alle brugere oplever koldstart p\u00e5 samme tid efter implementeringen.<\/p>\n\n<h2>RAM-di\u00e6t og realistisk kapacitetsplanl\u00e6gning<\/h2>\n\n<p>I stedet for faste v\u00e6rdier beregner jeg det gennemsnitlige og \u00f8verste RAM-behov pr. worker med live-trafik. Herfra udleder jeg: (tilg\u00e6ngeligt RAM \u2013 system\/DB\/caches) \/ RAM pr. worker = <strong>maksimal<\/strong> fornuftig pm.max_children. Derudover holder jeg 15\u201325 % i reserve til burst, kernel-cache og uforudsete spikes. Hvis applikationen sporadisk oppuster hukommelsen, s\u00e6nker jeg gr\u00e6nsen eller reducerer pm.max_requests for at genbruge processer oftere.<\/p>\n\n<h2>Teststrategi: Reproducerbar belastning og realistiske m\u00f8nstre<\/h2>\n\n<p>Jeg bruger testprofiler, der blander kolde og varme caches, kombinerer GET\/POST og \u00f8ger samtidigheden gradvist. Vigtigt: F\u00f8rst med aktiv OPcache og realistiske t\u00e6nketider kan jeg se, om systemet forbliver stabilt under brugsadf\u00e6rd. En ramp-up over flere minutter forhindrer kunstige spidsbelastninger ved opstart. Evalueringen fokuserer p\u00e5 TTFB og P95\/P99, ikke kun p\u00e5 gennemsnitlig RTT eller ren req\/s.<\/p>\n\n<h2>Fejlbilleder fra praksis<\/h2>\n\n<ul>\n  <li>Mange 504 under Peak: FPM-k\u00f8 fuld, backlog for lille, timeouts p\u00e5 proxyen t\u00e6ttere end i FPM.<\/li>\n  <li>Stamming ved deployeringer: OPcache-fortr\u00e6ngninger, manglende opvarmning, for lille opcache.memory_consumption.<\/li>\n  <li>Gode gennemsnitsv\u00e6rdier, d\u00e5rlige P99: For mange langdistancel\u00f8b (I\/O, eksterne API'er), manglende circuit breaking.<\/li>\n  <li>H\u00f8j CPU, lav req\/s: Session-l\u00e5se eller ikke-cachelagrede databaseforesp\u00f8rgsler, der begr\u00e6nser serielt.<\/li>\n<\/ul>\n\n<h2>Driftsikkerhed og rollback<\/h2>\n\n<p>Enhver \u00e6ndring af handleren eller poolparametrene k\u00f8rer jeg med <strong>Funktionelle flag<\/strong> eller gradvist. Jeg holder \u00f8je med fejl- og slowlogs, P95 og fejlprocent og definerer en klar nedlukning, hvis m\u00e5lingerne tipper. En anden pool med identisk version, men andre parametre, muligg\u00f8r hurtig A\/B-skift uden nedetid. Under fuld belastning viser en kort, automatisk reduktion af samtidighed (backpressure) sig at v\u00e6re effektiv i stedet for at starte nye arbejdere ukontrolleret.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Til dynamiske websteder med mange samtidige brugere foretr\u00e6kker jeg <strong>LSAPI<\/strong> p\u00e5 LiteSpeed, mens PHP-FPM p\u00e5 Apache eller Nginx giver det bedste <strong>Allrounder<\/strong> mod_php forbliver et s\u00e6rligt tilf\u00e6lde for meget enkle projekter uden streng isolation. Det afg\u00f8rende er realistiske tests med varm OPcache, fornuftige poolgr\u00e6nser og ren caching. Hvis man p\u00e5lideligt reducerer latenstider, m\u00e5ler man P95\/P99 og reagerer f\u00f8rst p\u00e5 tail-problemer i stedet for gennemsnitsv\u00e6rdier. P\u00e5 den m\u00e5de opn\u00e5r en applikation m\u00e6rkbart hurtigere svar og flere reserver til spidsbelastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>PHP-handler-sammenligning viser, hvordan PHP-FPM, LSAPI og CGI p\u00e5virker webhosting-ydeevnen. Optimale hosting-tuning-tip til maksimal hastighed.<\/p>","protected":false},"author":1,"featured_media":16174,"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-16181","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":"2825","_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 Handler Vergleich","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":"16174","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/16181","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=16181"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/16181\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/16174"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=16181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=16181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=16181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}