Laravel Octane und RoadRunner: PHP bleibt endlich im Speicher
Bis vor kurzem: PHP startet für jeden Request von vorn. Script rein, Script raus – alles landet nach dem Request im Nirvana. Das war immer so. Mit Octane und RoadRunner läuft es anders. Nach dem ersten Start bleibt die Anwendung im Speicher, Requests werden an laufende Worker verteilt. Kein kompletter Neubeginn pro Aufruf mehr.
Das spart Zeit. Gerade unter Last. RoadRunner steuert die Worker, Octane verbindet das Ganze mit Laravel. Agenturen und Betreiber von SaaS-Anwendungen, die mit klassischen PHP-Setups immer wieder an Grenzen stoßen, können so deutlich mehr Nutzer bedienen – mit weniger Timeouts und weniger Support-Anfragen.
Praxis: 80 ms statt 800 ms – aber nicht ohne Tücken
Beispiel aus einem Agenturprojekt: SaaS-Lösung auf Laravel, ab 30 gleichzeitigen Nutzern wurde es zäh. 250 ms Antwortzeit im Leerlauf, 800 ms und mehr unter Last. Nach dem Wechsel auf Octane und RoadRunner: Antwortzeiten plötzlich unter 80 ms, auch bei 50 parallelen Nutzern. Serverlast: entspannter. Speicher: im Rahmen.
Entscheidend war die Konfiguration:
- Zwei Worker pro CPU-Kern – weniger bringt Engpässe, mehr macht die Kiste voll
- Cache- und Session-Handler auf persistente Prozesse umgestellt
- Keine Objekte im State, die sich nicht serialisieren lassen – sonst gibt’s Speicherlecks oder merkwürdige Fehler
Das Ergebnis: Weniger Timeouts, zufriedene Nutzer, weniger Tickets. Aber: Fertig ist damit nix.
Typische Stolpersteine: PHP ist nicht plötzlich magisch
Octane ist kein Plug-and-Play-Turbo. Persistenz bedeutet: Alles, was im Speicher bleibt, wirkt weiter. Fehler kommen oft dort, wo keiner sie erwartet.
- Datenbankverbindungen werden nicht sauber zurückgesetzt – irgendwann streikt die DB
- Caches leben zu lang – alter Kram bleibt hängen
- Sessions und Auth bauen auf Request-Grenzen, die es so nicht mehr gibt
Gern vergessen: Middleware oder Event-Listener, die auf einmal in einen Zombie-Zustand kippen. Websockets und Queue-Worker machen dann Dinge, die im klassischen PHP nie vorkamen. Im Forum poppen dazu ständig kuriose Bugs auf. Wer Octane im Shared Hosting versucht, kann sich die Zeit sparen. Geht nicht. Ressourcen und Kontrolle braucht’s – Shared Hosting ist raus.
RoadRunner selbst ist auch kein Selbstläufer. Ohne Erfahrung oder Doku werden Limits schnell falsch gesetzt, Worker crashen weg oder Anfragen bleiben einfach liegen. Typisch: Nach ein paar Tagen Betrieb häufen sich die Geisterprozesse.
Server-Anforderungen 2026: Shared Hosting war gestern
Wer Octane und RoadRunner einsetzen will, braucht Root-Zugriff. Mindestens VPS, besser Managed Root Server. Shared Hosting mit isolierten PHP-Prozessen: keine Chance.
Sinnvolle Basis:
- 4 CPU-Kerne aufwärts, 8 GB RAM oder mehr
- Linux & systemd für Services
- PHP 8.2 oder 8.3, Opcache und JIT an
- Datenbank mit Connection Pooling – PostgreSQL oder MySQL
Hybrid-Container gehen, sind aber auf Dauer kaum billiger oder flexibler als ein eigener Server. Shared Hosting bleibt außen vor.
Erfahrung nach fast 30 Jahren Webentwicklung
Octane und RoadRunner sind von der Spielwiese runter. Wer mit Laravel arbeitet, kriegt endlich Node.js-Tempo ohne Framework-Wechsel. Aber: Die neuen Fehlerquellen sind echt. In Altprojekten rächt sich jeder vergessene Singleton oder globale State brutal. Tests dauern länger, Debugging wird kniffliger. In Agenturen mit mehreren Entwicklern: Vor dem Go-Live unbedingt Zeit für Code-Reviews einplanen.
Monitoring und Logging müssen umgebaut werden. Viele Fehler tauchen erst nach 50 Requests auf – klassische Einzelscript-Logik hilft dann wenig.
Wer sauber vorbereitet, spart sich später richtig Ärger. In SaaS-Projekten und bei Plattformen mit viel Traffic lohnt sich der Aufwand aber schon nach ein paar Monaten.
Fazit: Schnell, aber nicht für jeden
Octane und RoadRunner machen PHP 2026 flott – aber nur, wenn Hosting und Code passen. Faktor 3 bis 5 mehr Geschwindigkeit ist drin. Wer persistente Prozesse ignoriert, fängt sich seltsame Bugs ein und legt den Betrieb lahm. Shared Hosting kann ab jetzt aus dem Lastenheft gestrichen werden. Wer wachsen will, muss in Testprozesse, Monitoring und Hosting investieren. Sonst wird aus der Performance-Party schnell ein Debugging-Marathon.
Weitere Artikel:
- PHP 8.4: Neue Stolpersteine, neue Chancen – was jetzt ansteht
- PHP-Altprojekte absichern: OWASP-Check für SQL-Injection, XSS und Session-Fixation
bye
mo