PHP Handler Vergleich: CGI, FPM und LSAPI im Hosting

PHP Handler Vergleich zeigt klar, wie CGI, PHP-FPM und LSAPI die Ausführung von PHP-Skripten steuern und damit Latenz, Isolation und RAM-Bedarf im Hosting prägen. Ich erläutere die Unterschiede praxisnah, ordne sie nach Workloads ein und gebe Empfehlungen für Auswahl und Konfiguration im täglichen Betrieb.

Zentrale Punkte

• Performance: LSAPI führt bei Tail-Latenzen, PHP-FPM liefert sehr konstante Antwortzeiten.
• Sicherheit: CGI trennt strikt, PHP-FPM isoliert mit Pools, LSAPI kapselt pro User.
• Ressourcen: LSAPI spart RAM, PHP-FPM bleibt effizient, CGI erzeugt Overhead.
• Kompatibilität: PHP-FPM passt zu Apache/Nginx, LSAPI glänzt mit LiteSpeed.
• Praxis: Für CMS und Shops setze ich meist auf PHP-FPM; viel Traffic profitiert oft von LSAPI.

Grundlagen der PHP-Handler

Ein PHP-Handler verbindet den Webserver mit dem PHP-Interpreter. CGI startet für jede Anfrage einen neuen Prozess und erreicht dadurch eine sehr saubere Trennung zwischen Accounts. Diese Trennung kostet Zeit, weil jede Anfrage Erweiterungen und Konfiguration erneut lädt. PHP-FPM hält Worker persistent und verteilt Anfragen auf Pools, was die Startkosten reduziert und die Latenz niedrig hält. LSAPI integriert sich tief in LiteSpeed und nutzt sehr leichte, langlebige Prozesse für hohe Effizienz.

Mod_php bindet PHP direkt in den Webserver, doch die Isolation fällt schwach aus. Ich bevorzuge moderne Handler, weil sie Fehlerquellen einkreisen und die Plattform unter Last stabiler halten. Wer viele Nutzer auf einem System hostet, profitiert klar von getrennten User-Kontexten. Genau hier spielen FPM-Pools und LSAPI ihre Stärken aus. CGI bleibt eine sichere, aber träge Option für sehr kleine Sites und spezielle Prüf-Szenarien.

Vergleichstabelle: Stärken und Einsatzszenarien

Die folgende Tabelle fasst die Kerneigenschaften zusammen und ordnet sie typischen Workloads zu. Ich nutze sie als schnelle Entscheidungshilfe bei hosting php-Setups mit CMS, Shops oder APIs. Beachte, dass die reale Leistung zusätzlich von Caching, Storage und Netzwerkprofil abhängt. Trotzdem bildet der Überblick eine solide Ausgangsbasis für eine erste Auswahl. Danach feine ich die Konfiguration anhand konkreter Lastprofile und Messwerten.

Handler	Performance	Sicherheit	RAM-Verbrauch	Skalierbarkeit	Geeignet für
CGI	Niedrig	Sehr hoch	Hoch	Niedrig	Tests, statische oder selten aufgerufene Seiten
PHP-FPM	Sehr hoch	Hoch	Niedrig	Hoch	Shared Hosting, CMS, APIs
LSAPI	Höchste	Mittel bis hoch (pro User)	Sehr niedrig	Sehr hoch	High-Traffic, E‑Commerce, Concurrency

CGI punktet mit Trennung, leidet aber unter Prozess-Startkosten. PHP-FPM bringt das beste Verhältnis aus Latenz, Durchsatz und Isolation auf Systemen mit Apache oder Nginx. LSAPI liefert auf LiteSpeed-Stacks sehr niedrige Tail-Latenzen bei hoher Konkurrenz. Wer keinen LiteSpeed-Server nutzt, erhält mit FPM die breiteste Unterstützung. Für sehr kleine Seiten bleibe ich bei einfachen Setups; bei wachsenden Projekten schalte ich auf FPM oder LSAPI um.

Performance unter Last: Latenzen und Durchsatz

Unter ansteigender Konkurrenz zählen vor allem P95/P99-Latenzen und die Stabilität des Durchsatzes. LSAPI hält die höchsten Lasten mit erstaunlich gleichmäßigen Antwortzeiten. PHP-FPM folgt dicht dahinter und reagiert sehr gut auf Pool-Tuning, etwa mit dynamischer Prozesszahl. CGI verliert spürbar an Tempo, sobald viele kurze Requests eintreffen. Für tiefergehende Messungen verweise ich auf meinen Performance-Vergleich, der typische CMS- und Shop-Workloads abdeckt.

Ich kombiniere FPM oder LSAPI konsequent mit OPcache, damit Bytecode nicht ständig neu entsteht. Zusätzlich reduzieren Reverse-Proxy-Caches die Zahl der PHP-Hits bei wiederkehrenden Inhalten. Für rechenintensive Tasks lohnt sich eine Job-Queue, damit Frontend-Anfragen schnell bleiben. Wer sporadische Spitzen abfängt, nutzt kurzlebiges Burst-Scaling über zusätzliche FPM-Worker. So bleiben Tail-Latenzen im Rahmen und die Antwortzeiten konsistent.

Sicherheit und Isolation im Shared Hosting

In Mehrnutzer-Umgebungen zählt Isolation mindestens so sehr wie Tempo. CGI erreicht durch per-Request-Prozesse eine sehr saubere Trennung, jedoch mit viel Overhead. PHP-FPM isoliert pro Pool und erlaubt harte Grenzen für Memory, Ausführungszeit und Prozesszahl. LSAPI ordnet Prozesse ebenfalls Konten zu, ist aber im Detail an den LiteSpeed-Stack gebunden. Wer Risiken einordnen will, liest am besten meinen Artikel zu Pool-Risiko bei FPM und zieht klare Grenzwerte ein.

Ich setze für jeden Account einen separaten Pool mit eigener UID/GID und restriktiven Rechten. So begrenze ich den Radius möglicher Angriffe und verhindere, dass fehlerhafte Skripte fremde Daten sehen. Dazu gehören Limits für Memory, maximale Requests pro Worker und Timeouts. Regelmäßige Updates und abgesicherte Dateirechte runden das Konzept ab. Offen ins Netz stehende Admin-Skripte minimiere ich oder schütze sie mit Auth.

Ressourcenverbrauch und RAM-Management

RAM entscheidet oft über Kosten und Dichte pro Server. LSAPI punktet hier mit sehr kleinem Footprint pro Prozess und sparsamen Kontextwechseln. PHP-FPM bleibt ebenfalls effizient, wenn ich Pools dynamisch anlege und Limits sauber dimensioniere. CGI verschwendet Speicher durch häufiges Neuladen von Erweiterungen und eignet sich daher kaum für dynamische Projekte. Wer viele Accounts hostet, gewinnt mit FPM oder LSAPI deutlich mehr Reserven pro Knoten und hält die Gesamtkosten planbar.

Ich messe regelmäßig Peak-RAM und beobachte die Verteilung über den Tag. Peaks deuten auf zu niedrige Workerzahlen oder ungünstige Caching-Strategien hin. Mit feinerem Pool-Sizing und gezieltem OPcache-Tuning senke ich den Bedarf. Das reduziert Swap-Risiken und beugt unvorhersehbaren Latenzausreißern vor. Auf überfüllten Hosts verschiebe ich einzelne Sites auf eigene Knoten, bevor die Gesamtleistung leidet.

Kompatibilität mit Apache, Nginx und LiteSpeed

Die Wahl des Webservers lenkt die Entscheidung beim Handler. PHP-FPM arbeitet hervorragend hinter Nginx und lässt sich mit Apache via Proxy sauber anbinden. In Apache-Umgebungen rate ich zu mpm_event, Keep-Alive-Tuning und einer stabilen Proxy-Konfiguration. LSAPI entfaltet sein volles Potenzial mit LiteSpeed und liest .htaccess-Dateien effizient aus. Wer bereits auf LiteSpeed setzt, holt mit LSAPI oft das letzte Stück Leistung heraus.

Für statische Inhalte bediene ich Nginx oder LiteSpeed direkt aus dem Webserver-Cache. PHP bearbeitet nur, was dynamisch bleiben muss. Diese Trennung senkt die Last auf den Handler und spart CPU-Zeit. Als Nebeneffekt steigt die TTFB-Konstanz bei wiederkehrenden Seitenaufrufen. So bleiben Frontends reaktionsschnell, selbst wenn Backends unter Druck stehen.

Best Practices für PHP-FPM-Pools

Ich beginne mit einem konservativen Pool-Layout pro Site und messe reale Spitzen. Danach passe ich pm, pm.max_children, pm.start_servers und pm.max_requests an. Zu kleine Pools lassen Anfragen warten, zu große Pools fressen RAM und erzeugen Kontextwechsel. Für WordPress, WooCommerce oder TYPO3 wähle ich in der Regel dynamic oder ondemand und reguliere die Grenzen eng. Details zu pm.max_children habe ich in meinem Leitfaden pm.max_children zusammengefasst.

Limits wie memory_limit und max_execution_time setze ich pro Pool. Damit verhindere ich, dass einzelne Skripte Ressourcen blockieren oder ausufern. request_terminate_timeout schützt vor hängenden Prozessen, die sich sonst stapeln. max_input_vars und upload_max_filesize sichere ich sinnvoll ab, je nach Projekt. So bleiben Pools kontrollierbar und der Host stabil.

Caching und OPcache in der Praxis

OPcache gehört für mich zu jeder PHP-Installation. Ich aktiviere ihn, kontrolliere die Größe und beobachte die Hit-Rate. Bei vielen Deployments setze ich file_cache_only und tune revalidate_freq, damit Deployments schnell greifen. Zusätzlich nutze ich Reverse-Proxy-Caches und Page-Cache-Plugins in CMS, um die PHP-Trefferquote zu senken. Je weniger Requests tatsächlich in PHP landen, desto besser skaliert alles.

Wer serverseitige Sessions intensiv nutzt, profitiert häufig von Redis. Dabei reguliere ich TTLs und verwalte Speicherlimits strikt. Für Full-Page-Cache überlege ich mir Cache-Keys und Invalidation-Strategien, damit Shops nach Preis- oder Lageränderungen korrekt ausliefern. Ein klarer Cache-Plan spart CPU, RAM und Zeit. Das Zusammenspiel aus OPcache, Proxy-Cache und Anwendungs-Cache entscheidet am Ende über die wahrgenommene Geschwindigkeit.

Entscheidungsmatrix: Welcher Handler passt zu welchem Projekt?

Kleine Sites mit wenig Traffic laufen sicher mit PHP-FPM und konservativen Limits. Reine Testumgebungen oder spezielle Compliance-Vorgaben können CGI sinnvoll machen, trotz Tempoverlust. High-Traffic-Shops und stark konkurrierende APIs profitieren oft von LSAPI auf LiteSpeed. Wer maximale Kompatibilität und Flexibilität braucht, landet zuverlässig bei FPM. Für hosting php mit WordPress oder WooCommerce ziehe ich FPM als vielseitigen Allrounder vor.

Ich treffe die Entscheidung nie allein auf Basis eines Benchmarks. Stattdessen messe ich den realen Mix aus statischen Hits, dynamischen Seiten und API-Calls. Auch die durchschnittliche Skriptzeit und der Anteil von Cache-Treffern beeinflusst die Wahl. Zusätzlich berücksichtige ich Admin-Gewohnheiten, etwa häufige Deployments oder Build-Prozesse. Die beste Lösung bleibt die, die unter echten Bedingungen stabil und schnell läuft.

Kosten, Lizenz und Betrieb – was rechnet sich?

Auf reinen Kostensichtungen wirkt FPM attraktiv, da es ohne zusätzliche Lizenzen auskommt. LSAPI kann durch bessere Dichte und niedrigere Latenzen die Betriebskosten pro Site senken, erfordert aber LiteSpeed-Lizenzen in Euro. Bei vielen zahlenden Kunden rechnet sich das häufig, bei Hobbyprojekten meist nicht. CGI verursacht indirekte Kosten durch ineffiziente Ressourcennutzung und längere Antwortzeiten. Ich kalkuliere daher Gesamtbetrieb und spare dort, wo es die Qualität nicht gefährdet.

Wichtig bleibt die Planbarkeit. Ein Host, der zu stark überbucht ist, spart kurzfristig, zahlt aber mit Ausfällen und unzufriedenen Nutzern. Moderne Observability-Tools helfen, Engpässe früh zu erkennen. Wer regelmäßig Kapazität nachzieht, hält Latenzen stabil und entlastet den Support. Am Ende gewinnt die Lösung, die Ressourcen schont und die Uptime hoch hält.

Multi‑PHP-Versionen, Rollouts und Zero‑Downtime

Im Alltag betreibe ich häufig mehrere PHP-Versionen parallel. Mit FPM gelingt das sauber über getrennte Pools und eigene Sockets je Version. So kann ich Sites schrittweise migrieren, ohne das Gesamtsystem zu stören. Ich plane rollierende Updates: Erst Staging, dann eine kleine Produktionsgruppe, schließlich der Rest. Graceful Reloads (FPM: reload statt restart) vermeiden harte Abrisse und halten Verbindungen offen. Bei LSAPI nutze ich analoge Mechanismen im LiteSpeed-Stack, um Worker vorzuwärmen und den Cold-Start-Effekt zu minimieren.

Für Zero-Downtime-Deployments achte ich auf atomare Releasestrategien mit Symlinks und OPcache-Invalidierung. Nach dem Umschalten leere ich selektiv Caches, ohne alles zu verwerfen. So bleiben Tail-Latenzen stabil, und neue Deployments landen schnell im Warmzustand. Wichtig: File-Permissions und Besitzer stimmen, sonst blockieren FPM- oder LSAPI-Worker bei neuen Releases.

Sockets vs. TCP: Architekturentscheidungen mit Folgen

Die Anbindung des Handlers erfolgt entweder per Unix-Socket oder via TCP. Sockets sparen Overhead und liefern meist minimal bessere Latenzen auf einem Host. TCP lohnt sich, wenn Webserver und Handler getrennt laufen oder wenn ich Pools auf mehrere Knoten skalieren möchte. Für TCP definiere ich Timeouts, Keep-Alive und Backlog sauber, damit bei Lastspitzen keine 502/504-Fehler auftauchen. In Apache-Setups beachte ich die Zahl aktiver Proxy-Worker, in Nginx die Limits für offene Verbindungen. Bei LSAPI übernimmt LiteSpeed vieles intern, dennoch prüfe ich Backlog und Warteschlangen regelmäßig unter Last.

Ich beobachte die Queue-Länge am FPM-Status, die Auslastung der Worker und die CPU-Sättigung. Hohe Queue bei niedriger Auslastung weist oft auf Engpässe im Frontend (z. B. zu wenige Nginx-Worker) oder auf I/O‑Bremsen hin. Erst wenn ich den Flaschenhals kenne, erhöhe ich Kinderprozesse oder passe Netzwerk-Parameter an.

Monitoring, Metriken und Fehlersuche

Zur Beobachtung setze ich auf Holistic Monitoring: Webserver-Logs, FPM-Status, Systemmetriken (CPU, RAM, I/O), Applikations-Logs und synthetische Checks. Besonders wertvoll ist der FPM‑Slowlog, um Ausreißer aufzuspüren. Ich korreliere P95/P99-Latenzen mit CPU‑Spitzen, OPcache-Hit-Rate, Anzahl laufender Prozesse und Datenbanklatenzen. Steigt die P99-Latenz, prüfe ich zuerst Warteschlangen und Timeouts zwischen Proxy und Handler.

Im Incident-Fall arbeite ich von außen nach innen: 1) HTTP-Fehlercodes und Zeitpunkt, 2) Proxy-/Webserver-Fehler, 3) Handler-Queues und Worker-Zustände, 4) Applikationslogs, 5) Backend-Systeme (DB, Cache, Filesystem). Häufige Ursachen für 502/504 sind zu strenge Timeouts, blockierende Upstreams oder erschöpfte Pool-Kapazitäten. Einfache Gegenmaßnahme: realistische Timeouts, klare Limits und ein Alerting, das vor der Erschöpfung meldet.

Dateisysteme, realpath und OPcache-Details

Dateizugriffe prägen die Latenz stärker als viele erwarten. Ich achte auf schnelle Storage-Pfade für Code und Templates. Auf Netzwerk-Filesystemen (z. B. NFS) sind realpath- und OPcache-Parameter kritisch. Eine ausreichend große realpath_cache_size und ein passendes ttl verhindern permanente Pfadauflösungen. Im OPcache dimensioniere ich memory_consumption, interned_strings_buffer und die Anzahl der Hash-Tabellen so, dass die Hit-Rate hoch bleibt und Rehashing selten ist. validate_timestamps und revalidate_freq stelle ich passend zum Deployment-Workflow ein, damit Änderungen rasch greifen, aber nicht jede Sekunde Checks auslösen.

Bei großen Codebasen lohnt sich Preloading für zentrale Klassen und Funktionen. So sparen FPM- oder LSAPI-Worker CPU-Zeit im Hot Path. Ich teste JIT nur dort, wo es echte CPU-Bottlenecks gibt (viel numerische Logik). Für klassische CMS bringt JIT selten Vorteile; wichtiger ist eine saubere OPcache-Konfiguration und ein schneller I/O-Pfad.

Datenbank- und Cache-Anbindung: Latenz vermeiden

Viele Performance-Probleme stammen nicht aus dem Handler, sondern aus Datenbanken und Caches. Ich überwache Query-Laufzeiten, Connection-Pools und Locks. Persistente Verbindungen können helfen, aber sie binden RAM in den Workern. Deshalb dimensioniere ich pm.max_children im Einklang mit Verbindungsgrenzen der Datenbank und steuere Timeouts. Für Redis-/Memcached‑Zugriffe sind niedrige Netzwerklatenz und Zeitouts ebenso entscheidend. Ich ziehe Tracing in der Anwendung hinzu, um N+1‑Queries zu erkennen und zu reduzieren – das senkt die Last auf Handler und Backend zugleich.

Unter hoher Konkurrenz ist es oft sinnvoll, schreibende Vorgänge zu entkoppeln (Queues, Async-Jobs) und lesende Zugriffe zu cachen. So bleiben Frontend-Requests kurz und die Variabilität der Antwortzeiten sinkt.

Container, Chroot und OS‑Aspekte

Wer FPM oder LSAPI in Containern betreibt, gewinnt Flexibilität bei Versionen und Limits. Wichtig sind korrekte ulimits, ein effizienter Prozess-Scheduler und passende CPU-/Memory-Quoten. Zu harte Quoten erzeugen Stottern in P99-Latenzen. In klassischen Setups hilft chroot/jail oder eine Nutzerisolation über Namespaces, um Dateizugriffe strikt zu trennen. Ich halte die Images schlank, um Cold-Start-Zeiten (z. B. nach einem Rollout) kurz zu halten, und wärme Pools vor, bevor der Traffic umschwenkt.

Logrotation und Backpressure-Strategien sind Pflicht: Volllaufende Disks oder blockierende Log-Schreiber wirken direkt auf Antwortzeiten. Ebenso kalibriere ich Swappiness, HugePages (wo sinnvoll) und NUMA-Strategien auf Hosts mit vielen Kernen, damit Worker nicht durch Speicherzugriffe über Knoten hinweg ausgebremst werden.

LSAPI- und FPM-Feinheiten im Betrieb

LSAPI profitiert von stabilen, langlebigen Prozessen und effizientem Request-Dispatch. Ich reguliere die maximale Requestzahl pro Worker, um Memory‑Leak‑Effekte zu begrenzen, und beobachte Restarts im Livebetrieb. Bei FPM wähle ich ondemand für Sites mit unregelmäßigem Traffic, dynamic für stetige Last. pm.max_requests definiere ich so, dass sporadische Leaks oder Fragmentierung keine Rolle spielen. request_slowlog_timeout setze ich eng genug, um echte Hänger früh zu erkennen, aber nicht so eng, dass komplexe Admin-Operationen pausenlos Alarm schlagen.

Bei beiden Welten verifiziere ich die Signalwege für Reloads und lege Eskalationspfade fest, falls Worker nicht sauber neu starten. Das verhindert, dass ein Deployment mitten am Tag Unruhe in die Plattform bringt.

Checkliste: Auswahl und Tuning in der Praxis

• Ziel definieren: maximale Kompatibilität (FPM) vs. minimalste Tail-Latenz (LSAPI) vs. sehr harte Trennung (CGI).
• Serverrolle klären: Ein-Host-Setup (Unix-Socket) oder getrennte Ebenen (TCP) – Timeouts/Backlog passend setzen.
• Pools je Account/Site: eigene UID/GID, enge Limits für Memory, Requests und Zeit; Slowlog aktivieren.
• OPcache: ausreichende Größe, hohe Hit-Rate, revalidate-Strategie passend zum Deployment; ggf. Preloading.
• Storage: schneller Pfad für Code/Cache, realpath‑Cache dimensionieren, NFS-Besonderheiten beachten.
• DB/Cache: Verbindungen und Timeouts konsistent zu pm.max_children; N+1‑Queries eliminieren.
• Caching-Layer: Reverse-Proxy, Page-Cache und Anwendungs-Cache kombinieren; invalidieren statt blind leeren.
• Observability: P95/P99, Queue-Länge, Worker-Zustände, OPcache-Hit-Rate, I/O und Backend-Latenzen im Blick.
• Rollouts: Graceful reloads, Warmup, atomare Deployments, selektive Cache-Invalidierung.
• Kapazitätsplanung: Burst-Reserven, keine Überbuchung; Kosten/Nutzen von LSAPI-Lizenzen realistisch bewerten.

Kurz zusammengefasst: meine Einordnung

Für gemischte Hosting-Umgebungen liefert PHP-FPM die beste Balance aus Performance, Isolation und Kompatibilität. Auf LiteSpeed-Stacks bringt LSAPI messbare Vorteile bei Tail-Latenzen und RAM-Verbrauch. CGI eignet sich für strikte Trennung in Nischenfällen, fällt bei dynamischen Projekten jedoch zurück. Ich setze zuerst auf FPM mit klaren Pool-Grenzen, aktiviertem OPcache und sauberem Webserver-Setup. Wer besonders viel Konkurrenz erwartet, testet LSAPI auf LiteSpeed und trifft danach eine Kosten-Nutzen-Entscheidung.