Hochschulwebsites laufen den größten Teil des Jahres problemlos und geraten an einer Handvoll besonders stark frequentierter Tage ins Straucheln. Die Ursache ist selten ein zu kleiner Server. Vielmehr können an diesen Tagen die meisten Seiten nicht mehr aus einer gespeicherten Kopie ausgeliefert werden. Dieser Artikel erklärt verständlich, wie Drupal Seiten speichert, was ein CDN beschleunigt und was nicht, und wo Sie ansetzen sollten, damit die Website standhält.
Eine Seite lädt im März in einer halben Sekunde und braucht am ersten Morgen der Einschreibung zehn Sekunden. Dieselbe Website, derselbe Code. Geändert hat sich nur, wie viele Seiten der Server an diesem Tag von Grund auf neu erstellen musste. Eine Drupal-Website zu beschleunigen bedeutet vor allem, diese Zahl zu senken.
Wann wird eine Hochschulwebsite tatsächlich langsam?
Den größten Teil des Jahres ist die Mehrheit der Besucher nicht angemeldet. Studieninteressierte stöbern in den Studiengängen, Eltern öffnen die Kontaktseite, Suchmaschinen durchsuchen den Newsbereich. All diese Besuche lassen sich aus einer gespeicherten Kopie beantworten, und der Server hat kaum etwas zu tun.
An Spitzentagen ändert sich diese Mischung. Ein großer Teil der Besucher sind nun angemeldete Studierende. Sobald sich jemand anmeldet, wird die Seite persönlich, und eine für alle gespeicherte Kopie passt nicht mehr. Der Server beginnt, Tausende Seiten gleichzeitig von Grund auf neu zu erstellen.
Zwei weitere Faktoren kommen hinzu. Platzzahlen und Stundenpläne werden aus einem anderen System gelesen und können nicht lange vorgehalten werden, weil sie nicht veralten dürfen. Und wenn sich der akademische Kalender oder eine hochschulweite Mitteilung ändert, muss jede Seite, die diese Informationen anzeigt, neu erstellt werden.
Fallen alle drei Faktoren in dieselbe Woche, wird die Website langsam. Ziel ist nicht, an einem durchschnittlichen Tag ein paar Millisekunden einzusparen. Ziel ist, diese Tage ohne Ausfall zu überstehen.
Wie Drupal Seiten speichert
Nachdem Drupal eine Seite erstellt hat, behält es eine Kopie davon. Die nächste Person, die dieselbe Seite aufruft, erhält die gespeicherte Kopie, statt zu warten, bis die Seite erneut erstellt wird. Das ist der Hauptgrund, warum sich eine Drupal-Website schnell anfühlt, und es funktioniert ohne zusätzliche Konfiguration.
Für nicht angemeldete Besucher
Das ist der einfache Fall. Alle sehen dieselbe Seite, also genügt eine gespeicherte Kopie für alle. Studiengangsseiten, News und Kontaktdaten gehen aus derselben Kopie an Tausende Menschen, und der Server leistet nahezu keine Arbeit.
Für angemeldete Nutzer
Sobald sich jemand anmeldet, gehört ein Teil der Seite nur noch dieser Person: ihr Name, ihre Benachrichtigungen, ihre Kurse. Eine einzige, für alle gespeicherte Kopie lässt sich nicht mehr verwenden.
Drupal löst das, indem es die Seite in zwei Teile aufteilt. Die Bereiche, die für alle gleich sind, werden weiterhin gespeichert, und nur die persönlichen Bereiche werden bei jedem Besuch neu erstellt. So wird nur ein Bruchteil der Seite neu aufgebaut statt der ganzen Seite.
Sind diese persönlichen Bereiche dennoch langsam, kommt BigPipe ins Spiel. Der Ansatz wurde ursprünglich bei Facebook entwickelt und von Drupal in den Core übernommen. Die Funktionsweise ist einfach: Die gemeinsamen Teile der Seite werden sofort gesendet, die persönlichen folgen, sobald sie fertig sind. So sieht der Besucher, wie sich die Seite füllt, statt auf einen leeren Bildschirm zu starren. Laut der Drupal-Dokumentation ist BigPipe seit Version 8.5 in der Standardinstallation standardmäßig aktiviert und läuft damit bereits auf den meisten Websites.
| Nicht angemeldete Besucher | Angemeldete Nutzer | |
|---|---|---|
| Wie die Seite ankommt | Aus einer gespeicherten Kopie | Gemeinsame Teile gespeichert, persönliche Teile neu erstellt |
| Aufwand für den Server | Nahezu keiner | Etwas Arbeit bei jedem Besuch |
| Risiko an einem Spitzentag | Gering | Hier liegt die Last |
Was passiert, wenn sich Inhalte ändern
Die Schwierigkeit beim Speichern von Seiten liegt nicht darin, den Speicher zu füllen. Sie liegt darin, die richtigen Seiten im richtigen Moment zu aktualisieren. Auf einer Hochschulwebsite erscheint dieselbe Information an Dutzenden Stellen. Der Name einer Lehrkraft steht gleichzeitig in einer Fachbereichsliste, auf einer Kursseite und in einer Meldung.
Drupal merkt sich, von welchen Inhalten jede gespeicherte Seite abhängt. Ändert sich ein solcher Inhalt, aktualisiert Drupal nur die davon abhängigen Seiten und lässt den Rest unberührt. Eine einzelne Namensänderung zieht sich also nicht durch die gesamte Website.
Der eigentliche Fehler ist hier die Gewohnheit, nach jeder Änderung alles zu leeren. Das zwingt die gesamte Website zum Neuaufbau, und meist geschieht das im ungünstigsten Moment. Die Lösung: Hören Sie auf, diesen Button als Teil der täglichen Routine zu behandeln.
Was ein CDN beschleunigt und was nicht
Ein CDN liefert die Dateien einer Website von weltweit verteilten Servern aus, sodass Bilder, Videos und Schriften von einem Ort in der Nähe des Besuchers kommen. Auf Hochschulwebsites machen diese Dateien den Großteil des Seitengewichts aus, der Gewinn ist also real.
Auf Drupal-Seite übernimmt das das CDN-Modul. Ein Detail ist für die Planung wichtig: Die stabile Version funktioniert mit Drupal 9 und 10, während die Unterstützung für Drupal 11 noch getestet wird. Eine Einrichtung, die bereits Drupal 11 einsetzt, sollte das im Voraus wissen.
Nach der Installation folgt oft ein typischer Fehler: Sobald das CDN läuft, gilt das Performance-Problem als gelöst. Ein CDN verteilt jedoch fertige Dateien, es erstellt keine Seiten. Die persönliche Seite, die ein angemeldeter Studierender sieht, wird jedes Mal auf dem eigenen Server der Hochschule erstellt, und genau dort liegt an einem Spitzentag die Last.
Die IT-Seiten von Hochschulen sagen das klar. Die Drupal-Richtlinien einer großen staatlichen Universität weisen Website-Verantwortliche darauf hin, dass ihr CDN nur für nicht angemeldete Besucher gilt und angemeldete Nutzer es vollständig umgehen. Stanford geht bei dieser Unterscheidung noch einen Schritt weiter. Die dortigen IT-Services beschreiben eine zentral verwaltete Drupal-Plattform für Websites von Fachbereichen und Einrichtungen sowie eine separate Hosting-Option für Websites mit hohem Traffic. Nicht jede Website wird gleich behandelt.
Seiten mit Live-Daten
Platzzahlen, Stundenpläne und Ergebnisse stammen aus einem anderen System und dürfen nicht veralten. Weil sie sich nicht speichern lassen, sind sie die aufwendigsten Seiten der Website.
Drei einfache Maßnahmen helfen. Erstens: Trennen Sie das Live-Element vom Rest der Seite, sodass jedes Mal nur dieser kleine Teil neu erstellt wird und alles drumherum gespeichert bleibt. Zweitens: Geben Sie ihm eine kurze Lebensdauer statt gar keiner. Eine Platzzahl, die bis zu einer Minute alt ist, ist in den meisten Situationen akzeptabel, und diese Minute erspart dem anderen System Tausende Abfragen. Drittens: Legen Sie fest, was die Seite anzeigt, wenn das andere System nicht antwortet. Den letzten bekannten Wert mit Zeitstempel anzuzeigen ist besser, als gar nichts anzuzeigen.
Die Datenseite dieser Seiten haben wir im Beitrag Drupal-Integration mit dem Campus-Management-System behandelt.
Viele Websites auf einer Plattform betreiben
Viele Hochschulen betreiben Dutzende Websites von Fakultäten und Einrichtungen auf einer gemeinsamen Installation. Daraus folgt eine verbreitete Annahme: Weil die Websites eine Plattform teilen, müssen auch die gespeicherten Kopien geteilt werden. Das ist nicht der Fall. Jede Website hat ihre eigenen.
Das hat zwei Folgen. Eine Verbesserung auf einer Website überträgt sich nicht von selbst auf die anderen. Und weil Websites auf einem gemeinsamen Server auch dessen Ressourcen teilen, kann eine arbeitsreiche Woche bei einem Fachbereich die Seiten eines anderen verlangsamen.
Die weiteren Vor- und Nachteile dieses Aufbaus behandeln wir im Beitrag Hochschulwebsites mit Drupal Multisite verwalten. Für die Performance lautet die praktische Schlussfolgerung: Ermitteln Sie, welche Websites Lastspitzen haben, und planen Sie für diese gesondert.
Was Sie messen sollten
Messwerkzeuge haben einen blinden Fleck, den man kennen sollte. Die meisten testen die Website ohne Anmeldung und sehen daher nie die Seiten, die an einem Spitzentag in die Knie gehen. Eine Startseite kann perfekt abschneiden, während die Kurswahl zusammenbricht.
Deshalb braucht es zwei Perspektiven. Die erste umfasst die Seiten, die Besucher ohne Anmeldung sehen. Googles Geschwindigkeitsmetriken bewerten diese Seite und fließen ins Suchranking ein; darauf sind wir im Beitrag Drupal SEO eingegangen. Die zweite umfasst die Seiten, die angemeldete Nutzer sehen, gemessen auf dem Server statt im Browser, und dort liegt in der Regel das eigentliche Problem.
Die nützlichste Messung steht Ihnen bereits zur Verfügung. Die Serverlogs Ihrer arbeitsreichsten Woche im vergangenen Jahr verraten Ihnen mehr als jedes Testwerkzeug. Dort ist festgehalten, welche Seiten zu welcher Stunde aufgerufen wurden und welche Anfragen nie abgeschlossen wurden.
Wo Sie anfangen sollten
Bewährt hat sich, mindestens einen Monat vor der Spitze zu beginnen und in folgender Reihenfolge vorzugehen.
Prüfen Sie zunächst, ob die Caching-Einstellungen aktiviert sind. Das ist eine Prüfung von einer halben Stunde, doch auf Websites, auf denen etwas deaktiviert war, bringt sie den größten Unterschied der gesamten Liste.
Gehen Sie als Nächstes die Seiten durch, die angemeldete Nutzer sehen, und ermitteln Sie, welche Teile wirklich persönlich sind. Auf den meisten Websites sind das weniger als erwartet, und alles andere lässt sich speicherbar machen.
Trennen Sie dann die Elemente mit Live-Daten ab, geben Sie jedem eine sinnvolle Lebensdauer und legen Sie fest, was jedes anzeigt, wenn das andere System nicht verfügbar ist.
Führen Sie schließlich einen Test durch, der der arbeitsreichsten Stunde des Vorjahres nachgebildet ist. Dieser Test muss als angemeldeter Nutzer laufen, sonst werden die Seiten, die das Problem verursachen, nie geprüft.
Es lohnt sich, parallel zur Arbeit die Erwartungen abzustimmen. Drupal bietet hier starke Werkzeuge, doch sie kommen nicht auf Ihre Einrichtung abgestimmt an. Wie veraltet eine Information jeweils sein darf, ist eine institutionelle und keine technische Entscheidung, und sie wird gemeinsam mit dem Studierendensekretariat getroffen.
Die Drupal-Plattformen, die das Drupal4edu-Team von Drupart für Einrichtungen wie die Yeditepe-Universität, die Istinye-Universität und die Medipol-Universität entwickelt, sind genau auf diese Weise darauf ausgelegt, solche Lastspitzen abzufangen. Mehr über unseren Ansatz lesen Sie auf der Seite Drupal im Hochschulbereich.
Häufige Fragen zur Geschwindigkeit von Drupal-Websites
Behebt ein größerer Server die Verlangsamung?
Bis zu einem gewissen Punkt, aber es ist der teuerste Weg. Die meisten Seiten, die an Spitzentagen Probleme machen, werden neu erstellt, weil sie nicht aus einer gespeicherten Kopie kommen können. Mit korrigierten Caching-Einstellungen bewältigt derselbe Server weit mehr Besucher. Die sinnvolle Reihenfolge lautet: zuerst die Einstellungen prüfen, alles Nicht-Persönliche speicherbar machen und erst dann über Hardware sprechen, falls es noch nicht reicht.
Reicht ein CDN allein aus?
Nein. Ein CDN verteilt Bilder, Videos und Schriften und reduziert so das Seitengewicht spürbar. Die persönliche Seite, die ein angemeldeter Studierender sieht, wird jedoch in jedem Fall auf dem eigenen Server der Hochschule erstellt, und dort liegt an einem Spitzentag die Last. Wer ein CDN als nützliche Ergänzung und nicht als Hauptlösung betrachtet, erzielt ein realistischeres Ergebnis.
Lassen sich Live-Werte wie Platzzahlen überhaupt speichern?
Kurzzeitig ja, und in den meisten Fällen sollten sie das auch. Eine Platzzahl, die bis zu einer Minute alt ist, ist meist akzeptabel, und diese Minute verhindert, dass Tausende Abfragen das andere System erreichen. Entscheidend ist, die Lebensdauer bewusst zu wählen und mit dem Studierendensekretariat abzustimmen. Ebenso wichtig ist, dass die Seite nicht leer bleibt, wenn das andere System nicht verfügbar ist, sondern den letzten bekannten Wert mit Zeitstempel anzeigt.
Sollte der Cache nach jeder Änderung geleert werden?
Nein, und diese Gewohnheit sollten Sie ablegen. Drupal merkt sich, von welchen Inhalten jede gespeicherte Seite abhängt, und aktualisiert die betroffenen Seiten selbstständig, wenn sich etwas ändert. Alles zu leeren zwingt die gesamte Website zum Neuaufbau, und das geschieht meist im arbeitsreichsten Moment. Heben Sie diesen Button für Ausnahmefälle auf, statt ihn zum täglichen Reflex zu machen.