PHP & Event-Streaming: Wann ist Schluss?
2026, und jeder will irgendwas mit Live-Daten. Sei es für Benachrichtigungen, Dashboards oder den üblichen Chat-Schnickschnack. Klingt simpel: PHP-Script, bisschen flush(), fertig? Leider nicht. Wer das mit Standard-PHP (FPM, mod_php, was halt so läuft) probiert, merkt schnell: Die Nummer skaliert nicht. PHP arbeitet pro Request, blockt die Instanz für jede offene Verbindung. Fünf Nutzer? Geht noch. Fünfzig? Da fängt’s an zu rauchen.
Versuch mal, SSE oder WebSockets direkt aus PHP raus anzubieten. Die Prozesse stehen ewig rum, Streams reißen gerne ab, und Lastspitzen? Viel Spaß beim Debuggen. Im Ernst: Für mehr als Mini-Projekte reicht das selten. Wer Echtzeit will, muss das Setup anpassen. Sonst wird aus Live schnell Dead.
SSE oder WebSockets – Wo passt was?
Server-Sent Events (SSE): Der Klassiker für Live-Ticker, Push-Status, einfache Notifications. Einseitig – Server sendet, Browser lauscht. Geht über HTTP/1.1 oder HTTP/2. Einziger Vorteil: Schnell gebaut, keine Zusatztools nötig. Für einfache Broadcast-Fälle reicht das wirklich.
WebSockets gehen anders ran. Vollduplex, also hin und zurück. Ideal für Chats, Games, kollaborative Editoren, alles mit viel Interaktion. Bringt mehr Aufwand mit: Extra Server, Protokoll, eigene Prozesse. Wer die beiden sauber trennt – SSE für Push, WebSockets für Dialog – spart Nerven und Serverlast. In der Praxis: Mischbetrieb ist Alltag. Kein Drama, solange die Architektur nicht zum Spaghetti-Code mutiert.
PHP 2026: Was läuft wie zusammen?
PHP hat keinen Bock auf WebSockets, ehrlich gesagt. SSE kriegt man noch mit PHP-Scripts hin, wenn man flush() mag und Geduld hat. Für WebSockets braucht es Tools: Ratchet, Swoole, ReactPHP. Die laufen abseits vom klassischen Webserver, am besten als eigene Prozesse. Event-Loop inklusive, alles asynchron.
Das Standard-Setup sieht dann so aus:
- Klassischer PHP-Webserver für HTTP und SSE
- Separater WebSocket-Server (Swoole, Ratchet, ReactPHP)
- Message-Broker (Redis, RabbitMQ, NATS), der die Nachrichten zwischen den Teilen weiterreicht
PHP macht die Logik, WebSocket-Server hält die Connections. Kommunikation? Über den Broker. Kein Blockieren, kein Drama, solange der Broker nicht zum Flaschenhals wird.
Ressourcen: Die üblichen Stolperfallen
Viele versuchen’s: SSE oder WebSockets direkt in FPM oder mod_php. Ergebnis: Instanzen blockiert, Server ächzt, Streams brechen ab. Typischer Anfängerfehler. Besser:
- SSE-Streams kurz halten, regelmäßig Heartbeats und Timeouts einbauen
- WebSocket-Server immer als eigenen Prozess, nie aus PHP direkt starten
- Message-Broker einziehen – das entkoppelt und verteilt die Last
- Reverse Proxy (Nginx, Caddy) vorschalten, damit die langen Verbindungen sauber laufen
Wer so rangeht, hält auch bei vielen Nutzern die Kiste stabil. Monitoring nicht vergessen – Verbindungen, Speicher, CPU.
Skalierung: Ab wann wird’s hässlich?
WebSocket-Server merken sich Zustände. Das macht horizontales Skalieren nervig. Entweder: Nutzer immer an denselben Server binden (Sticky Sessions). Oder: Status zentral speichern (zum Beispiel in Redis), damit’s synchron bleibt. Die Events schiebt man über Message-Queues – sonst geht der Sync verloren.
SSE ist entspannter. Reicht meistens ein Loadbalancer davor. Streams sind einseitig, lassen sich verteilen. Aber: Auch hier gilt – Monitoring, und zwar nicht nur am Freitag um 17 Uhr. Sonst knallt’s garantiert am Montagmorgen.
Meine Einschätzung nach knapp 30 Jahren Webentwicklung
PHP ist 2026 immer noch Standard im Web. Aber: Wer Live-Daten will, braucht Zusatztools. Multi-Architektur. WebSocket-Server wie Swoole oder Ratchet, dazu einen Message-Broker. Anders geht’s ab mittleren Nutzerzahlen nicht mehr.
Agenturen mit 5 bis 10 Leuten? Die brauchen Infrastruktur und Know-how. Sonst bleiben Echtzeit-Features Wunschdenken. Die Investition ist kein Luxus, sondern Pflicht. Lösungen laufen damit sauberer, besser skalierbar. Einzelentwickler? Muss abwägen. Swoole und Konsorten lernt man nicht mal eben beim Kaffee. Da kann ein externer Dienst (Pusher, Ably) schneller ans Ziel führen – vor allem, wenn nur ein bisschen Live gebraucht wird.
Wer heute noch alles mit PHP-FPM und einem SSE-Script versucht, wird spätestens beim ersten größeren Event von der Realität eingeholt. Dauerverbindung im PHP-Prozess ist 2026 ein Anachronismus. Funktioniert nur noch bei Hobbyprojekten ohne Nutzer.
Weiterführende Artikel
- PHP 8.4: Neue Stolpersteine, neue Chancen – was jetzt ansteht
- PHP mit etwas JS: Wieso Agenturen 2026 meist keinen Framework-Zirkus brauchen
Fazit – PHP & Live: Geht, aber nicht mehr wie früher
Live-Features mit PHP sind 2026 nicht mehr die Domäne von Einzelscripten. Wer SSE oder WebSockets performant fahren will, braucht eigene Server, Message-Broker und eine klare Trennung im Stack. Dann läuft’s auch unter Last und spart Nerven – und auf Dauer Kosten.
bye
mo