PHP handler vergelijking: CGI, FPM en LSAPI in hosting

PHP Handler vergelijking laat duidelijk zien hoe CGI, PHP-FPM en LSAPI de uitvoering van PHP-scripts regelen en dus latency, isolatie en RAM-vereisten bij hosting karakteriseren. Ik leg de verschillen op een praktische manier uit, categoriseer ze op basis van werkbelasting en geef aanbevelingen voor selectie en configuratie bij dagelijks gebruik.

Centrale punten

• PrestatiesLSAPI leidt in staartlatenties, PHP-FPM levert zeer constante responstijden.
• BeveiligingCGI scheidt strikt, PHP-FPM isoleert met pools, LSAPI kapselt in per gebruiker.
• BronnenLSAPI bespaart RAM, PHP-FPM blijft efficiënt, CGI genereert overhead.
• CompatibiliteitPHP-FPM past bij Apache/Nginx, LSAPI schittert met LiteSpeed.
• PraktijkVoor CMS en shops gebruik ik meestal PHP-FPM; veel verkeer heeft vaak baat bij LSAPI.

Basisprincipes van PHP handlers

Een PHP handler verbindt de webserver met de PHP-interpreter. CGI start een nieuw proces voor elk verzoek en bereikt zo een zeer schone scheiding tussen accounts. Deze scheiding kost tijd omdat elk verzoek extensies en configuratie opnieuw laadt. PHP-FPM houdt workers persistent en verdeelt verzoeken over pools, wat opstartkosten verlaagt en latentie laag houdt. LSAPI integreert diep met LiteSpeed en gebruikt zeer lichte, langlevende processen voor Hoog rendement.

Mod_php integreert PHP direct in de webserver, maar de isolatie is zwak. Ik geef de voorkeur aan moderne handlers omdat ze foutbronnen minimaliseren en het platform stabieler houden onder belasting. Als je veel gebruikers op één systeem host, heb je duidelijk baat bij aparte Gebruikerscontexten. Dit is precies waar FPM pools en LSAPI hun sterke punten uitspelen. CGI blijft een veilige maar trage optie voor zeer kleine sites en speciale testscenario's.

Vergelijkingstabel: Sterke punten en toepassingsscenario's

De volgende tabel vat de belangrijkste functies samen en wijst ze toe aan typische werklasten. Ik gebruik het als een snelle beslissingshulp voor hosting php-opstellingen met CMS, shops of API's. Houd er rekening mee dat de werkelijke prestaties ook afhangen van caching, opslag en netwerkprofiel. Desalniettemin biedt het overzicht een solide startpunt voor een eerste selectie. Vervolgens verfijn ik de configuratie op basis van specifieke belastingsprofielen en Gemeten waarden.

handelaar	Prestaties	Beveiliging	RAM-verbruik	Schaalbaarheid	Geschikt voor
CGI	Laag	Zeer hoog	Hoog	Laag	Tests, statische of zelden geraadpleegde pagina's
PHP-FPM	Zeer hoog	Hoog	Laag	Hoog	Gedeelde hosting, CMS, API's
LSAPI	Hoogste	Gemiddeld tot hoog (per gebruiker)	Zeer laag	Zeer hoog	Veel verkeer, e-commerce, gelijktijdigheid

CGI scoort met Scheiding, maar heeft last van opstartkosten voor processen. PHP-FPM biedt de beste verhouding tussen latency, throughput en isolatie op systemen met Apache of Nginx. LSAPI levert zeer lage tail latencies met veel concurrentie op LiteSpeed stacks. Als je geen LiteSpeed server gebruikt, biedt FPM de breedste ondersteuning. Voor zeer kleine sites houd ik het bij eenvoudige opstellingen; voor groeiende projecten schakel ik over naar FPM of LSAPI.

Prestaties onder belasting: latentie en doorvoer

Onder toenemende concurrentie, P95/P99 latenties en de Stabiliteit van de doorvoer. LSAPI houdt de hoogste belastingen vast met verrassend consistente responstijden. PHP-FPM volgt op de voet en reageert erg goed op pooltuning, bijvoorbeeld met dynamische procesnummers. CGI verliest merkbaar snelheid zodra er veel korte verzoeken binnenkomen. Voor meer gedetailleerde metingen, zie mijn Prestatievergelijking, die typische CMS en shop werklasten dekt.

Ik combineer FPM of LSAPI consequent met OPcache, zodat bytecode niet steeds opnieuw wordt gegenereerd. Daarnaast verminderen reverse proxy caches het aantal PHP hits voor terugkerende inhoud. Een jobwachtrij is de moeite waard voor rekenintensieve taken zodat verzoeken aan de voorkant snel blijven. Als je sporadische pieken wilt opvangen, gebruik dan kortstondige burst scaling via extra FPM workers. Dit houdt de staartlatentie binnen de perken en de Reactietijden consistent.

Beveiliging en isolatie bij shared hosting

Wat telt in multi-user omgevingen Isolatie minstens evenveel als snelheid. CGI bereikt een zeer zuivere scheiding door processen per verzoek, maar met veel overhead. PHP-FPM isoleert per pool en staat harde limieten toe voor geheugen, uitvoeringstijd en aantal processen. LSAPI wijst ook processen toe aan accounts, maar is tot in detail gebonden aan de LiteSpeed stack. Als je risico's wilt categoriseren, kun je het beste mijn artikel over Risico bundelen met FPM en stelt duidelijke grenzen.

Ik heb voor elke account een aparte account ingesteld. zwembad met zijn eigen UID/GID en beperkende rechten. Dit beperkt de actieradius van mogelijke aanvallen en voorkomt dat foute scripts externe gegevens kunnen zien. Dit omvat limieten voor geheugen, maximale aanvragen per werker en time-outs. Regelmatige updates en veilige bestandspermissies ronden het concept af. Ik beperk beheerscripts die openlijk beschikbaar zijn op het netwerk tot een minimum of bescherm ze met Auth.

Bronnenverbruik en RAM-beheer

RAM bepaalt vaak Kosten en dichtheid per server. LSAPI scoort hier met een zeer kleine footprint per proces en zuinige contextswitches. PHP-FPM blijft ook efficiënt als ik pools dynamisch aanmaak en limieten goed dimensioneer. CGI verspilt geheugen door het veelvuldig herladen van extensies en is daarom nauwelijks geschikt voor dynamische projecten. Als je veel accounts host, geeft FPM of LSAPI je aanzienlijk meer reserves per node en blijft de Totale kosten planbaar.

Ik meet regelmatig piek RAM en observeer de verdeling over de dag. Pieken duiden op te lage aantallen werkers of ongunstige cachingstrategieën. Ik verminder de vraag met een fijnere pool sizing en gerichte OPcache tuning. Dit vermindert swap risico's en voorkomt onvoorspelbare latency uitschieters. Op overbezette hosts verplaats ik individuele Sites op zijn eigen knooppunten voordat de algehele prestaties eronder lijden.

Compatibiliteit met Apache, Nginx en LiteSpeed

De keuze van de webserver is leidend voor de beslissing bij de handelaar. PHP-FPM werkt uitstekend achter Nginx en kan netjes via een proxy verbonden worden met Apache. In Apache-omgevingen raad ik mpm_event, keep-alive tuning en een stabiele proxyconfiguratie aan. LSAPI ontvouwt zijn volledige potentieel met LiteSpeed en leest .htaccess bestanden efficiënt. Degenen die LiteSpeed al gebruiken krijgen vaak het laatste beetje performance met LSAPI. Prestaties uit.

Voor statische inhoud gebruik ik Nginx of LiteSpeed rechtstreeks vanuit de cache van de webserver. PHP verwerkt alleen wat dynamisch moet blijven. Deze scheiding vermindert de belasting van de handler en bespaart CPU-tijd. Als neveneffect neemt de TTFB-consistentie toe bij terugkerende paginaverzoeken. Dit betekent dat frontends responsief blijven, zelfs als Backends onder druk staan.

Best practices voor PHP FPM pools

Ik begin met een conservatieve Zwembadindeling per site en meet echte pieken. Vervolgens pas ik pm, pm.max_children, pm.start_servers en pm.max_requests aan. Te kleine pools laten verzoeken wachten, te grote pools verbruiken RAM en genereren contextwisselingen. Voor WordPress, WooCommerce of TYPO3 kies ik meestal voor dynamisch of ondemand en regel ik de limieten strak. Details over pm.max_children kun je vinden in mijn handleiding pm.max_kinderen samengevat.

Ik stel limieten in zoals memory_limit en max_execution_time per pool. Dit voorkomt dat individuele scripts bronnen blokkeren of uit de hand lopen. request_terminate_timeout beschermt tegen hangende processen die zich anders zouden opstapelen. max_input_vars en upload_max_filesize zijn verstandig beveiligd, afhankelijk van het project. Dit houdt pools bestuurbaar en de host stabiel is.

Caching en OPcache in de praktijk

Voor mij maakt OPcache deel uit van elke PHP-installatie. Ik activeer het, controleer de grootte en bewaak de hitrate. Voor veel implementaties stel ik file_cache_only in en stem ik revalidate_freq af zodat implementaties snel effect hebben. Ik gebruik ook reverse proxy caches en pagina cache plugins in CMS om de hitrate van PHP te verlagen. Hoe minder verzoeken er daadwerkelijk in PHP terechtkomen, hoe beter het schaalt. alles.

Degenen die server-side sessies intensief gebruiken, hebben vaak baat bij Redis. Ik regel TTL's en beheer geheugenlimieten strikt. Voor full-page cache overweeg ik cachingsleutels en invalidatiestrategieën zodat winkels correct leveren na prijs- of voorraadwijzigingen. Een duidelijk cacheplan bespaart CPU, RAM en tijd. De interactie van OPcache, proxy cache en Toepassingscache bepaalt uiteindelijk de waargenomen snelheid.

Beslismatrix: Welke handler past bij welk project?

Kleine sites met weinig verkeer werken veilig met PHP-FPM en conservatieve limieten. Pure testomgevingen of speciale compliance-eisen kunnen CGI nuttig maken, ondanks het snelheidsverlies. Winkels met veel verkeer en zeer concurrerende API's hebben vaak baat bij LSAPI op LiteSpeed. Als je maximale compatibiliteit en flexibiliteit nodig hebt, kun je vertrouwen op FPM. Voor php-hosting met WordPress of WooCommerce geef ik de voorkeur aan FPM als een veelzijdige Alleskunner voor.

Ik neem nooit een beslissing op basis van alleen een benchmark. In plaats daarvan meet ik de werkelijke mix van statische hits, dynamische pagina's en API-aanroepen. Ook de gemiddelde scripttijd en het aandeel cache-hits beïnvloeden de keuze. Ik houd ook rekening met beheergewoonten, zoals frequente implementaties of bouwprocessen. De beste oplossing blijft degene die werkt onder echte Voorwaarden stabiel en snel.

Kosten, licentie en werking - wat loont?

Op puur kostenoverzichten FPM aantrekkelijk omdat er geen extra licenties voor nodig zijn. LSAPI kan de operationele kosten per site verlagen door een betere dichtheid en lagere latencies, maar vereist LiteSpeed licenties in euro's. Voor veel betalende klanten loont dit vaak, maar voor hobbyprojecten meestal niet. CGI veroorzaakt indirecte kosten door inefficiënt gebruik van bronnen en langere responstijden. Ik bereken daarom de totale operatie en bespaar waar het zinvol is. kwaliteit niet in gevaar.

Het vermogen om te plannen blijft belangrijk. Een host die te zwaar overboekt is, bespaart geld op de korte termijn, maar betaalt dat terug met downtime en ontevreden gebruikers. Moderne observatietools helpen om knelpunten in een vroeg stadium te herkennen. Wie regelmatig capaciteit toevoegt, houdt latencies stabiel en ontlast support. Uiteindelijk is de oplossing die resources spaart en zo min mogelijk Uptime hoog.

Multi-PHP-versies, rollouts en geen downtime

In het dagelijks leven werk ik vaak met verschillende PHP versies parallel. Met FPM gebeurt dit netjes via aparte pools en aparte sockets voor elke versie. Hierdoor kan ik sites stap voor stap migreren zonder het hele systeem te verstoren. Ik plan rollende updates: eerst staging, dan een kleine productiegroep, dan de rest. Sierlijke herlaadbeurten (FPM: reload in plaats van restart) harde tear-offs te vermijden en verbindingen open te houden. Met LSAPI gebruik ik analoge mechanismen in de LiteSpeed stack om workers voor te verwarmen en het cold-start effect te minimaliseren.

Voor zero-downtime implementaties besteed ik aandacht aan atomic release strategieën met symlinks en OPcache validatie. Na het overschakelen wis ik selectief caches zonder alles weg te gooien. Dit houdt staartlatenties stabiel en nieuwe implementaties landen snel in een warme staat. Belangrijk: Bestandspermissies en -eigenaars moeten correct zijn, anders blokkeren FPM of LSAPI workers nieuwe releases.

Sockets vs. TCP: architecturale beslissingen met gevolgen

De handler is verbonden via Unix socket of via TCP. Sockets besparen overhead en leveren meestal minimaal betere latencies op een host. TCP is de moeite waard als de webserver en handler apart draaien of als ik pools wil verdelen over meerdere nodes. Schaal zou willen. Voor TCP definieer ik timeouts, keep-alive en backlog netjes zodat er geen 502/504 fouten optreden tijdens belastingpieken. In Apache setups let ik op het aantal actieve proxy workers, in Nginx op de limieten voor open verbindingen. Met LSAPI handelt LiteSpeed veel dingen intern af, maar ik controleer nog steeds regelmatig de backlog en wachtrijen onder belasting.

Ik monitor de wachtrijlengte op de FPM status, het gebruik van de workers en de CPU verzadiging. Een hoge wachtrij met een laag gebruik wijst vaak op knelpunten in de frontend (bijvoorbeeld te weinig Nginx-werkers) of I/O remmen daar. Pas als ik weet waar het knelpunt zit, verhoog ik de kindprocessen of pas ik de netwerkparameters aan.

Monitoring, statistieken en foutopsporing

Voor observatie vertrouw ik op Holistische monitoringWeb server logs, FPM status, systeem statistieken (CPU, RAM, I/O), applicatie logs en synthetische controles. Bijzonder waardevol is de FPMSlowlog, om uitschieters te detecteren. Ik correleer P95/P99 latenties met CPU spikes, OPcache hit rate, aantal draaiende processen en database latenties. Als de P99 latentie toeneemt, controleer ik eerst de wachtrijen en timeouts tussen proxy en handler.

Bij een incident werk ik van buiten naar binnen: 1) HTTP foutcodes en tijd, 2) proxy/webserver fouten, 3) handler queues en worker states, 4) applicatie logs, 5) backend systemen (DB, cache, bestandssysteem). Veel voorkomende oorzaken van 502/504 zijn te strenge timeouts, het blokkeren van upstreams of uitgeput Poolcapaciteiten. Eenvoudige tegenmaatregel: realistische time-outs, duidelijke limieten en waarschuwingen dat voor van uitputting.

Bestandssystemen, realpath en OPcache details

Bestandstoegang heeft een grotere invloed op latency dan veel mensen verwachten. Ik let op snelle Opslagpaden voor code en sjablonen. Op netwerkbestandssystemen (zoals NFS) zijn de parameters realpath en OPcache kritisch. Een voldoende grote realpath_cache_size en een geschikte ttl voorkomen permanente padresoluties. In de OPcache dimensioneer ik memory_consumption, interned_strings_buffer en het aantal Hasjtabellen zodat de hit rate hoog blijft en rehashing zeldzaam is. Ik stel validate_timestamps en revalidate_freq in om overeen te komen met de deployment workflow zodat veranderingen snel effect hebben maar niet elke seconde controles triggeren.

Voor grote codebases is het de moeite waard om Voorladen voor centrale klassen en functies. Dit bespaart FPM- of LSAPI-werkers CPU-tijd in het "hot path". Ik test JIT alleen als er echte CPU knelpunten zijn (veel numerieke logica). JIT levert zelden voordelen op voor klassieke CMS; een schone OPcache configuratie en een snel I/O pad zijn belangrijker.

Database- en cacheverbinding: latentie vermijden

Veel prestatieproblemen komen niet door de handler, maar door Databases en caches. Ik monitor query runtimes, verbindingspools en vergrendelingen. Persistente verbindingen kunnen helpen, maar ze binden RAM in de werkers. Ik dimensioneer pm.max_children daarom in overeenstemming met de verbindingslimieten van de database en controleer timeouts. Voor Redis/Memcached toegang zijn lage netwerklatentie en timeouts ook cruciaal. Ik gebruik tracing in de applicatie om N+1 queries te herkennen en te verminderen - dit vermindert tegelijkertijd de belasting van de handler en backend.

Het is vaak zinvol bij veel concurrentie, schrijven ontkoppel processen (wachtrijen, async taken) en cache leestoegang. Dit houdt front-end verzoeken kort en vermindert de variabiliteit van responstijden.

Container, chroot en OS aspecten

Iedereen die FPM of LSAPI gebruikt in Containeren wint aan flexibiliteit met versies en limieten. Correcte ulimieten, een efficiënte procesplanner en geschikte CPU/geheugenquota's zijn belangrijk. Te harde quota's veroorzaken stotteren in P99 latencies. In klassieke opstellingen helpt chroot/jail of gebruikersisolatie via namespaces om bestandstoegang strikt te scheiden. Ik houd de images mager om koude starttijden kort te houden (bijvoorbeeld na een rollout) en pools voor te verwarmen voordat het verkeer overschakelt.

Logboekrotatie en Tegendruk-strategieën zijn verplicht: volle schijven of blokkerende logboekschrijvers hebben een direct effect op de responstijden. Ik kalibreer ook swappiness, HugePages (waar nodig) en NUMA-strategieën op hosts met veel cores zodat werkers niet vertraagd worden door geheugentoegang tussen nodes.

LSAPI- en FPM-eenheden in werking

LSAPI profiteert van stabiele, langdurige processen en efficiënte verzending van verzoeken. Ik regel het maximum aantal verzoeken per werker om geheugenlekken te beperken en herstarts tijdens live werking te monitoren. Met FPM kies ik voor ondemand voor sites met onregelmatig verkeer, dynamisch Ik definieer pm.max_requests zo dat sporadische lekken of fragmentatie geen rol spelen. Ik stel request_slowlog_timeout dichtbij genoeg in om echte hangs vroeg te herkennen, maar niet zo dichtbij dat complexe beheeroperaties constant alarm slaan.

Voor beide werelden controleer ik de Signaalwegen voor herladen en escalatiepaden definiëren als werkers niet netjes herstarten. Dit voorkomt dat een implementatie midden op de dag een verstoring van het platform veroorzaakt.

Checklist: Selectie en afstemming in de praktijk

• Doel definiëren: maximaal Compatibiliteit (FPM) vs. minimale staartlatentie (LSAPI) vs. zeer harde scheiding (CGI).
• Verduidelijk de rol van de server: One-host setup (Unix socket) of aparte niveaus (TCP) - Stel timeouts/backlog op de juiste manier in.
• Pools per account/site: eigen UID/GID, strakke limieten voor geheugen, aanvragen en tijd; activeer slowlog.
• OPcache: voldoende grootte, hoge trefkans, revalidatiestrategie geschikt voor implementatie; indien nodig vooraf laden.
• Opslag: snel pad voor code/cache, dimensie realpath cache, NFS speciale kenmerken observeren.
• DB/Cache: Verbindingen en timeouts consistent met pm.max_children; elimineer N+1 queries.
• Cachinglaag: Combineer reverse proxy, paginacache en applicatiecache; ongeldig maken in plaats van blind legen.
• Waarneembaarheid: P95/P99, wachtrijlengte, worker states, OPcache hit rate, I/O en backend latencies in een oogopslag.
• Uitrol: Sierlijke herladen, opwarmen, atomaire implementaties, selectief ongeldig maken van cache.
• Capaciteitsplanning: barstreserves, geen overboeking; realistische beoordeling van de kosten/baten van LSAPI-licenties.

Kort samengevat: mijn classificatie

Voor gemengde hostingomgevingen PHP-FPM de beste balans tussen prestaties, isolatie en compatibiliteit. Op LiteSpeed stacks biedt LSAPI meetbare voordelen in termen van tail latencies en RAM-verbruik. CGI is geschikt voor strikte scheiding in nichegevallen, maar raakt achterop in dynamische projecten. Ik vertrouw in eerste instantie op FPM met duidelijke poollimieten, geactiveerde OPcache en een schone webserver setup. Als je veel concurrentie verwacht, test LSAPI dan op LiteSpeed en neem dan een beslissing. Kosten-baten-beslissing.