Bevor du über Octane, Redis oder größere Server nachdenkst, nimm dir einen einzigen echten Ablauf in deinem langsamen Laravel-Kundenportal vor und miss, wo die Wartezeit wirklich entsteht. Teile sie in Browser und Netzwerk, Laravel-Code, Datenbank, Cache, Queues und externe Dienste auf. Behebe dann den größten belegten Engpass. Eager Loading, passende Indizes, gezieltes Caching und Hintergrundjobs lösen unterschiedliche Probleme. Octane ist erst sinnvoll, wenn Messungen zeigen, dass der Request-Bootstrap oder der Durchsatz tatsächlich der Engpass ist und die Anwendung für langlebige Worker geprüft wurde.
- Vergleiche jede Änderung unter denselben Bedingungen und beobachte neben der Laufzeit auch Fehler, Warteschlangen und Ressourcensättigung.
- Plane Rollback, Cache-Invalidierung und Worker-Neustart als Teil des Releases.
Miss einen echten Ablauf, nicht das Framework
„Das Portal ist langsam“ ist keine Diagnose. Für einen Kunden kann damit die Anmeldung gemeint sein, für einen Sachbearbeiter die Suche, für die Geschäftsführung ein Bericht und für den Support ein sporadischer Timeout. Dieselbe Anwendung kann in diesen Abläufen völlig unterschiedliche Engpässe haben.
Definiere deshalb zuerst einen prüfbaren Ablauf, zum Beispiel: „Ein angemeldeter Kunde öffnet seine Vorgangsliste, filtert nach Status und lädt die Detailansicht.“ Halte Datenmenge, Berechtigungsprofil, Browser, Netzwerkbedingungen und Anwendungsversion fest. Miss dann Antwortzeiten als Verteilung statt als Durchschnitt: Median, p95 und p99 beantworten unterschiedliche Fragen. Dazu kommen Fehlerrate, Datenbankzeit, Zahl und Form der Abfragen, Wartezeit externer Dienste, Queue-Lag und die im Browser sichtbare Reaktionsfähigkeit.
Wichtig: Ein schneller Test mit leerer Datenbank beweist nichts über einen realen Kundenablauf. Nutze repräsentative, datenschutzgerecht vorbereitete Datenmengen und reproduzierbare Bedingungen. Produktionsdaten gehören nicht unkontrolliert in eine Testumgebung.
Laravel liefert dafür offizielle Einstiegspunkte. DB::listen ruft für jede SQL-Abfrage einen Listener auf, DB::whenQueryingForLongerThan reagiert, wenn die kumulierte Abfragezeit eines Requests einen Schwellwert überschreitet, und ein eingeplanter db:monitor-Lauf löst bei zu vielen offenen Verbindungen ein DatabaseBusy-Ereignis aus, aus dem erst ein eigener Listener eine Benachrichtigung macht.
Laravel Pulse zeigt langsame Requests und Abfragen, Queue-Durchsatz und Ausnahmen; Telescope erfasst einzelne Requests im Detail und muss außerhalb lokaler Umgebungen über das viewTelescope-Gate geschützt werden, denn Query-Bindings können sensible Werte enthalten; produktive Erfassung braucht Filterung, Zugriffsschutz und eine begrenzte Aufbewahrung.
Datenbank zuerst: Abfrageform, Datenmenge und Index
Bei datenreichen Portalen liegt der größte Hebel häufig nicht in einem schnelleren PHP-Worker, sondern in weniger oder besseren Datenbankoperationen. Drei Fragen kommen zuerst:
- Werden für eine Liste immer wieder dieselben Beziehungen einzeln nachgeladen?
- Holt die Anwendung mehr Spalten oder Zeilen, als der Nutzer für diesen Schritt braucht?
- Kann die Datenbank Filterung, Sortierung und Verknüpfung mit einem passenden Zugriffspfad ausführen?
Ein N+1-Problem entsteht, wenn eine erste Abfrage eine Sammlung lädt und anschließend pro Element weitere Abfragen folgen. Gezieltes Eager Loading lädt die benötigten Beziehungen in einer begrenzten Zahl von Abfragen, ist aber kein Freibrief, jeden denkbaren Zusammenhang vorzuladen: Zu viel davon erhöht Datenmenge, Speicherbedarf und Objektarbeit. In Entwicklungs- und Testumgebungen macht preventLazyLoading unerwartetes Lazy Loading sichtbar; die automatische Eager-Loading-Funktion ist in der aktuellen Laravel-Dokumentation als Beta gekennzeichnet, für einen kritischen Portalpfad ist eine explizite Ladeentscheidung deshalb leichter zu kontrollieren.
Ein Index hilft nur, wenn er zur tatsächlichen Filterung, Sortierung und Verknüpfung passt; einer auf Verdacht erhöht Schreibarbeit und Speicherbedarf, ohne die problematische Abfrage zu verbessern. MySQL und PostgreSQL dokumentieren EXPLAIN und EXPLAIN ANALYZE. Beide führen das jeweils unterstützte Statement mit EXPLAIN ANALYZE tatsächlich aus, weshalb die Prüfung bei schreibenden Statements in eine kontrollierte Umgebung gehört; PostgreSQL zeigt dafür ausdrücklich eine Transaktion mit anschließendem Rollback. Entscheidend ist nicht, ob „ein Index existiert“, sondern ob die Datenbank für den relevanten Datenstand einen geeigneten Plan wählt.
Auch Pagination ist eine Produktentscheidung mit technischer Wirkung: paginate ermittelt zusätzlich die Gesamtzahl, simplePaginate spart diese Zählabfrage, und Cursor-Pagination kann bei großen, passend indexierten und eindeutig sortierten Datenmengen effizienter sein, bietet aber keine Seitennummern. Wenn der Nutzer „Seite 37 von 812“ wirklich braucht, hat die Gesamtzählung einen fachlichen Wert.
Cache nur mit Eigentümer, Gültigkeit und Invalidierung
Cache eignet sich für teure Ergebnisse, die häufiger gelesen als geändert werden und für einen definierten Zeitraum wiederverwendet werden dürfen. Laravel bietet dafür Cache::remember; Cache::flexible setzt das stale-while-revalidate-Muster um, liefert also innerhalb eines zweiten Zeitfensters ein älteres Ergebnis aus, während die Neuberechnung nach der Antwort läuft. Ob das fachlich zulässig ist, hängt vom Inhalt ab: Eine nahezu aktuelle Auswertung darf veraltet sein, eine gerade geänderte Berechtigung nicht. Jeder Cache braucht vier klare Antworten:
- Welche fachlichen und Berechtigungsdimensionen gehören in den Schlüssel, etwa Mandant, Nutzer, Sprache oder relevante Filter?
- Wie lange darf das Ergebnis fachlich veraltet sein?
- Welches Ereignis macht es ungültig und welcher Codepfad übernimmt die Invalidierung?
- Was passiert bei einem kalten Cache oder einem Ausfall des Cache-Backends?
Sicherheitsgrenze: Ein zu grober Cache-Schlüssel kann Daten zwischen Mandanten oder Berechtigungsstufen vermischen. Mandanten- und Berechtigungsgrenzen müssen Teil des Entwurfs und der Tests sein, nicht eine nachträgliche Optimierung.
Queues und externe Dienste brauchen ein Zeitbudget
Eine interaktive Anfrage sollte nur die Arbeit enthalten, die für die nächste sichtbare Entscheidung des Nutzers erforderlich ist. Berichte erzeugen, Dateien verarbeiten oder umfangreiche Synchronisationen sind Kandidaten für Hintergrundjobs. Das verkürzt den Request und erhöht die betriebliche Verantwortung: Ein produktionsreifer Job braucht eine eindeutige fachliche Identität, kontrollierte Wiederholungen, Timeouts, Fehlerbehandlung und Beobachtbarkeit. Wiederholungen dürfen eine externe Buchung, Nachricht oder Zustandsänderung nicht unkontrolliert doppelt ausführen, und bei Datenbankänderungen muss klar sein, ob der Job erst nach erfolgreichem Commit laufen darf.
Ein eingeplanter queue:monitor-Lauf löst ein QueueBusy-Ereignis aus, wenn die Jobzahl einer Queue den Schwellwert überschreitet; für eine Benachrichtigung braucht es einen eigenen Listener. Für die Nutzererfahrung zählt aber nicht nur die Länge der Queue, sondern die Zeit bis zum fachlichen Ergebnis. Definiere deshalb ein Queue-Lag-Budget pro Jobklasse und überwache alte, wiederholt fehlgeschlagene sowie dauerhaft laufende Jobs.
Der Laravel HTTP Client unterstützt explizite Verbindungs- und Antwort-Timeouts sowie kontrollierte Wiederholungen. Verlasse dich in einem geschäftskritischen Ablauf nicht auf Standardwerte, sondern lege pro Abhängigkeit fest, wie lange der Nutzer warten darf, welche Fehler wiederholbar sind und ob ein Fallback fachlich korrekt ist.
Ein Retry bei einem sicheren Lesezugriff ist etwas anderes als bei einem schreibenden Aufruf: Wenn nach einem Timeout unklar ist, ob der entfernte Dienst die Operation ausgeführt hat, braucht der Prozess einen Idempotenzschlüssel. Für systemübergreifende Abläufe zeigt unsere Seite zur Automatisierung und Integration, wie Zeitbudgets, Idempotenz, Monitoring und fachliche Verantwortung zusammengehören.
Frontend und Deployment
Eine kurze Serverantwort garantiert kein schnelles Portal. Große JSON-Antworten, blockierendes JavaScript, nicht dimensionierte Medien oder zu viel Arbeit beim ersten Rendern verzögern die sichtbare Interaktion. Wenn derselbe Datensatz nach dem ersten Rendern von mehreren Komponenten erneut abgefragt wird, liegt das Problem möglicherweise in der Frontend-Datenarchitektur und nicht im Laravel-Controller. Core Web Vitals sind Feldmetriken: Ein Lighthouse-Score belegt weder ein schnelles Laravel-Backend noch bestandene Core Web Vitals. DUNAs dokumentierte Lighthouse-Methode zeigt, wie eine datierte Labormessung sauber eingeordnet wird.
Für Produktions-Deployments empfiehlt Laravel php artisan optimize, um Konfiguration, Events, Routen und Views zu cachen. Nach config:cache wird die Umgebungsdatei während Requests und Artisan-Befehlen nicht geladen, env() gehört daher ausschließlich in Konfigurationsdateien; eine falsche Annahme macht hier aus einer vermeintlichen Optimierung einen Produktionsfehler.
Ist bei PHP OPcache die Timestamp-Prüfung deaktiviert, muss der Release-Ablauf den Opcode-Cache ausdrücklich invalidieren, zurücksetzen oder den Webserver neu starten, damit neuer Code wirksam wird. Lang laufende Prozesse müssen zur neuen Version passen: Laravel 13 beschreibt dafür php artisan reload, das unter anderem Queue-, Reverb- und Octane-Prozesse beendet, damit ein korrekt konfigurierter Process Monitor sie mit dem neuen Code neu startet.
Eine neue Migration, ein verändertes Cache-Format oder bereits gestartete Jobs können die alte Version inkompatibel machen. Plane vor dem Release, welche Zustände beide Versionen lesen können und welche Änderung erst nach erfolgreicher Beobachtungsphase aktiviert wird.
Wann Octane sinnvoll ist und wann nicht
Laravel Octane startet die Anwendung einmal und hält sie für weitere Requests im Speicher; offiziell unterstützt sind derzeit FrankenPHP, Open Swoole, Swoole und RoadRunner. Das kann Bootstrap-Arbeit reduzieren, beseitigt aber keine ineffiziente SQL-Abfrage, keinen langsamen Drittanbieter und keine übergroße Browser-Payload. Durch das langlebige Prozessmodell gelten andere Annahmen, und die Laravel-Dokumentation warnt ausdrücklich vor veraltetem Request- oder Container-Zustand sowie möglichen Speicherlecks.
Setze Octane deshalb erst auf die Auswahlliste, wenn Profiling zeigt, dass nach Datenbank-, API- und Anwendungsoptimierung ein relevanter Anteil im Bootstrap oder in der Worker-Verarbeitung verbleibt. Vorher brauchst du Lasttests, Prüfungen auf zustandsbehaftete Komponenten, Grenzwerte für Worker-Neustarts, Monitoring und einen getesteten Rückweg.
Vom Signal zum passenden Hebel
| Beobachtung | Erforderlicher Beleg | Erster Hebel | Hauptrisiko | Verifikation |
|---|---|---|---|---|
| Hohe Serverzeit ohne Datenbank- oder API-Anteil | Request-Profil, Logs und Traces für den konkreten Ablauf | Unnötige Arbeit im Laravel-Code entfernen | Refactoring ohne belegten Anteil an der Gesamtzeit | Serverzeit vor und nach der Änderung vergleichen |
| Viele ähnliche Beziehungsabfragen | Query-Trace zeigt N+1 im relevanten Ablauf | Gezieltes Eager Loading oder andere Abfrageform | Zu viele Daten und höherer Speicherbedarf | Abfragezahl, Datenmenge und Latenz vergleichen |
| Langsame Filterung oder Sortierung | Ausführungsplan und repräsentative Datenmenge | Abfrage und passenden Index gemeinsam entwerfen | Zusätzliche Schreiblast oder ungeeigneter Plan bei anderer Verteilung | Plan, Laufzeit und Schreibwirkung prüfen |
| Teure stabile Leseoperation | Wiederholte Berechnung mit klarer Gültigkeitsdauer | Gezielter Cache | Veraltete oder falsch gescopte Daten | Hit-Rate, Invalidierung, Berechtigungs- und Ausfalltests |
| Request wartet auf Nebenarbeit | Profil zeigt abtrennbare nicht interaktive Arbeit | Idempotenter Hintergrundjob | Doppelte Wirkung, Queue-Lag oder unsichtbare Fehler | Ende-zu-Ende-Zeit, Fehler, Retries und Duplikate prüfen |
| Schwankende externe API | Abhängigkeit dominiert Trace oder Timeout | Zeitbudget, kontrollierter Retry, Cache oder Entkopplung | Retry-Sturm oder fachlich falscher Fallback | Fehlerszenarien und Idempotenz testen |
| Server schnell, Browser langsam | Netzwerk- und Hauptthread-Profil | Payload, JavaScript und Rendering-Pfad verbessern | Funktionale Regression oder verschobene Arbeit | Labortest plus Felddaten nach Release |
| Bootstrap dominiert nach anderen Korrekturen | Profil und Lasttest zeigen reproduzierbaren Anteil | Octane-Pilot | Zustandsleck, Speicherwachstum, Betriebsaufwand | Last-, Isolations-, Speicher- und Rollback-Test |
| Regression nur nach Releases oder veraltete Worker | Release-Marker in Metriken und Logs, Prozessstand | Deterministischer Build und kontrollierter Reload | Alter Code oder alte Konfiguration bleibt aktiv | Prozessversion, Konfigurations- und Route-Cache prüfen |
Jede Maßnahme braucht eine überprüfbare Hypothese. „Wir fügen Redis hinzu“ ist keine. Prüfbar wäre: „Die Berechtigungsübersicht wird pro Mandant häufig gelesen und wiederholt dabei dieselbe teure Aggregation; ein mandantenspezifischer Cache mit ereignisbasierter Invalidierung soll die Datenbankzeit dieses Ablaufs senken.“ Ein schnellerer Request, der veraltete Berechtigungen oder doppelte Vorgänge erzeugt, ist keine Verbesserung.
Belegte Referenz, klar begrenzt: Die veröffentlichte entsorgo-Fallstudie belegt Laravel-Delivery und einen schrittweisen Rollout, ohne das laufende Tagesgeschäft zu unterbrechen. Sie ist kein veröffentlichter Performance-Optimierungsfall und belegt keine Antwortzeit, keine Abfragezahl und keinen Cache-, Durchsatz- oder Einsparungswert.
Häufige Fragen zur Laravel-Performance
Warum ist mein Laravel-Kundenportal langsam?
Die Ursache kann in Datenbankabfragen, Laravel-Code, Cache, Queues, externen APIs, Netzwerk oder Frontend liegen. Miss zuerst einen konkreten Nutzerablauf und teile die Wartezeit auf diese Ebenen auf. Erst dann lässt sich der größte belegte Engpass sinnvoll priorisieren.
Macht Laravel Octane jedes Portal schneller?
Nein. Octane verschiebt die Grenze beim Request-Bootstrap und beim Durchsatz, repariert aber keine ineffiziente Abfrage, keine langsame externe API und keine große Browser-Payload. Es lohnt sich erst, wenn das Profil genau dort den Engpass zeigt und die Anwendung für langlebige Worker geprüft ist.
Wie vermeide ich N+1-Abfragen in Laravel?
Erfasse die Abfragen des betroffenen Ablaufs und lade genau die Beziehungen vor, die er braucht. Prüfe danach Abfragezahl, Datenmenge, Speicherbedarf und Antwortzeit. Pauschales Eager Loading erzeugt selbst unnötige Arbeit.
