Und wieder melde ich mich gut gelaunt und überhaupt nicht gefrustet aus dem Maschinenraum. Heute: Wie meine site()->index()-Abfragen meine Seite fast gekillt hätten. Und ich wie immer selbst daran schuld gewesen bin.

Aber von vorne.

Vielleicht war es keine gute Idee, an ein, zwei Abenden bei Trakt nachzupflegen, welche Serien ich alles schon gesehen habe. Denn das hat mich auf Ideen gebracht. Zum Beispiel: Ich könnte ja dann auch gleich alle Serien und alle Filme auf gesonderten Seiten ausgeben. Und bei Serien könnte ich ja auch noch, einfach weil es so schön ordentlich ist, die Staffeln sortieren und den Serien zuordnen.

Und wenn ich schon dabei bin: Das Ganze könnte ich doch langsam über APIs aufbauen. Klar, die Watchdaten sind nur so halb akkurat, weil ich erst ab diesem Zeitpunkt angefangen habe, Serien sauber zu tracken. Aber ganz ehrlich: Ein bisschen Unschärfe ist immer noch besser als gar keine Daten.

Und wenn ich dann schon ungefähre Watchdaten habe, kann ich ja auch direkt Watchlog-Einträge erzeugen. Wer weiß, wofür die noch gut sind.

Die Konsequenz? Plötzlich hatte meine Seite über 8.000 Watchlog-Einträge. Und über 8.126 Episoden und Filme. Mit einer Watchdauer von sage und schreibe 8,5 Monaten! Aber darum soll es hier gar nicht gehen. Manche Statistiken sollte man vielleicht einfach nicht berechnen.

Worum es geht: Ich hatte plötzlich keine kleine, gemütliche Seite mehr. Sondern ein leicht zickiges Monstrum, das morgens, wenn die Botschwärme aufwachen, meinen Server zuverlässig in die Knie zwingt.

Und schuld daran war natürlich ich.

Ich habe für jede kleine Anzeige von Content einfach site()->index() benutzt. Bedeutet: Immer erst einmal die komplette Website laden, alles durchscannen, tausende Seitenobjekte bauen und dann 99,9 Prozent davon wieder wegwerfen. Klassisches Beispiel:

„Gib mir alle Seiten, filtere Reviews raus, sortiere nach Datum und zeig mir die neuesten fünf.“

Das funktioniert. Aber eben nur so lange, wie die Seite klein ist.

Mit wachsendem Content wurde das zum Problem. Nicht, weil Kirby schlecht ist, sondern weil ich bequem war. „Hol alles, filter später“ ist einfach, aber teuer.

Was ich jetzt stattdessen mache:

Ich scanne die Inhalte genau einmal, ziehe mir daraus nur die relevanten IDs und speichere diese als Cache. Und danach arbeite ich nur noch mit diesem vorbereiteten Datensatz. Keine globalen Scans mehr pro Request, sondern ein vorbereiteter, günstiger Zugriff.

Das habe ich inzwischen umgesetzt für:

• Tag-Lookups
• Film- und Serienverzeichnisse
• Watchlog-Beziehungen
• den Home-Feed
• meine Stories-Rail

Das Prinzip ist immer gleich: einmal berechnen, dann cachen.

Dann kam die nächste „gute“ Idee: Prewarming. Also Seiten im Hintergrund vorladen, damit sie für euch schneller da sind. Klingt erstmal sinnvoll.

War es auch. Nur habe ich es natürlich übertrieben.

Ich habe das Prewarming als Self-Requests direkt bei normalen Seitenaufrufen eingebaut. Bedeutet: Ein Request erzeugt mehrere neue Requests auf sich selbst. Solange wenig Traffic da ist, geht das gut. Sobald aber Bots anfangen, parallel meine Seiten zu crawlen, kippt das System.

Und genau das ist passiert.

Bots wie GPTBot, AhrefsBot oder SemrushBot haben parallel angefangen, vor allem die Suche aggressiv abzuklappern. Gleichzeitig liefen meine eigenen Prewarm-Requests. Ergebnis: Alle Worker belegt, nichts geht mehr.

Deshalb habe ich jetzt zwei Dinge geändert:

Die Suche ist für Bots gesperrt
Prewarming passiert nur noch minimal, aktuell nur für die Startseite
Alles andere beobachte ich erstmal.

Die eigentliche Erkenntnis aus der ganzen Geschichte ist aber ziemlich simpel:

site()->index()ist nicht falsch, solange man es nicht übertreibt, so wie ich ich.

Wenn man es bewusst für globale Aufgaben nutzt, ist alles gut. Wenn man es aber im Frontend bei jedem Request mehrfach benutzt, während die Seite wächst und komplexer wird, dann baut man sich ziemlich zuverlässig einen Flaschenhals.