Sehr lange Reaktionszeiten nach längerer Pause

Ich weiss wir hatten dieses Thema schon einmal irgendwo. Nachdem es allerdings schon seit vielen Monaten, vielleicht Jahren so ist, will ich dem jetzt endlich auf den Grund gehen.

Worum es geht: Wenn eine Installation lange Zeit nicht aufgerufen wurde, dauert der erste Zugriff sehr sehr lang, das können durchaus 20 Sekunden sein. Es ist mir gerade eben wieder aufgefallen in einer relativ neuen Installation (Contao 4.9.3, vor einigen Tagen installiert). Ich wollte mich am Backend anmelden, aber es dauerte ca 20 Sekunden bevor die Login-Seite angezeigt wurde. Hoster ist Webgo, mein eigenes CMS Power Paket. aber es passiert auch in anderen Installationen bei Netcup, 1&1, ...

In der aktuell betrachteten Installation existiert kein echter Cronjob, also ist der Command-Scheduler nicht deaktiviert. Im System Log sehe ich, dass die entsprechenden Wartungsarbeiten vorgenommen wurden, bevor ich angemeldet wurde. Allerdings noch innerhalb der selben Minute, Sekunden werden im Log ja leider keine angezeigt. Kann das eine derart lange Wartezeit erklären? Zu löschen gab es definitiv nicht viel. Und ich erinnere mich dunkel, aufgrund des selben Effekts einmal bei einer Installation den Command-Scheduler einfach deaktiviert habe (ohne einen echten Cronjob zu erstellen) und dass dies damals nichts gebracht hat. Außerdem kann es natürlich so sein, dass zunächst die Login-Seite ausgeliefert wurde und danach erst die Wartungsarbeiten vorgenommen wurden. Erst danach konnte ich mich ja anmelden. So sollte es auch eigentlich sein. Allerdings bedeutet das dann, dass etwas anderes, mir unbekanntes, diese 20 Sekunden verbrät. Ich werde das jetzt aber trotzdem zuerst nochmal zu verifizieren versuchen. Das Phänomen ist auch nicht auf den Backend-Login beschränkt, es passiert auch beim Aufruf von Frontend-Seiten nach längerer Pause.

Zu dem Thema wurde auch gelegentlich berichtet, dass es nur bei Subdomains passiere, später im produktiven Betrieb nicht mehr. Dass es an der Subdomain liegt ist für mich erst einmal schwer vorstellbar. Eher daran, dass im produktiven Betrieb so lange Pausenzeiten eher ungewöhnlich sind und meist auch ein echter Cronjob eingerichtet ist, der automatisch dafür sorgt, dass zwischen zwei Aufrufen niemals Pausen der Größenordnung 1 Tag und mehr liegen können. Ob sich dann der Cronjob die lange Reaktionszeit fängt, ob es halt irgendeinen Besucher trifft oder ob es dann schlicht gar nie passiert weiss ich nicht. Den/die Threads finde ich leider gerade auch nicht mehr alle. Obwohl ich mich zu erinnern glaube, dass damals am Ende empfohlen wurde, mit einer Profiling-Software an die Sache ranzugehen, weil im Debugmodus der entsprechende Vorgang nicht genügend aufgelöst wurde.

Ich muss mir also jetzt zunächst einmal einen guten Plan zurecht legen, wie ich an die Sache rangehe, was ich wie untersuche, welche Werkzeuge ich benutzen sollte. Da stellen sich mir erst einmal einige Fragen:

1. Zuallererst, falls es nicht die Wartungsarbeiten sind, was kommt sonst noch als Übeltäter in Frage? Der Symfony-Cache sollte ja eigentlich nicht neu aufgebaut werden ohne konkrete Änderung - oder irre ich mich da? Falls doch, wie kann ich das aktuelle "Alter" des Symfony Caches bestimmen? Anhand des Datums der Dateien? Ansonsten ist die Installation jetzt auch nicht riesig, da gibt es m.E. sonst nichts, was auch nur annähernd so lange brauchen dürfte. Zumal darauffolgende Zugriffe auf andere Seiten der Installation grundsätzlich immer völlig "normale" Reaktionszeiten zeigen (TTFB).
2. Kann ich irgendwie eine lange Pause zwischen den Requests simulieren? Jedesmal 24 Stunden zu warten zwischen zwei Versuchen bremst natürlich gewaltig. Bis ich da auch nur ein vernünftiges Test-Setup, eventuell mit Profiler, realisiert habe ist die erste Woche schon rum.

Wenn inzwischen jemand schon weitergehende Erkenntnisse zu dem Problem gewonnen hat, wäre das natürlich auch eine große Hilfe.

https://github.com/contao/contao/issues/809

Danke, der Issue ist irgendwie an mir vorbeigegangen. Das heißt dann im Klartext, ich muss Hoster/Hostingpakete/PHP-Versionen/PHP-Einstellungen finden, die diesen unschönen Nebeneffekt guter Software-Architektur minimieren. Da bin ich wahrscheinlich froh, wenn ich ein oder zwei halbwegs akzeptable Kombinationen finde. Das heißt dann natürlich auch, jeder der bereits ein Webhosting irgendwo gebucht hat, wird mit ziemlich hoher Wahrscheinlichkeit entweder wechseln oder ein zweites Webhosting dazubuchen müssen. Weiterhin müssen die Vereine/Handwerker/kleine Selbständige/ halt damit leben, dass das trotzdem gelegentlich passiert, wenn auch vielleicht nur mit 5 Gedenksekunden statt 20. Wenn sie das nicht wollen, muss ich ihnen entweder einen richtig konfigurierten Managed Server verkaufen oder eine Website, die z.B. mit einem Static Site Generator oder einem Baukasten erzeugt wird. Das wird dann wohl ein nicht unbeträchtlicher Anteil werden in Zukunft, angesichts dessen, was Google über die Aufbauzeiten von Webseiten predigt. Schade, aber wohl unvermeidlich :(. Kann nur hoffen, dass es bei den bereits ausgelieferten Websites nicht auffällt, sonst kann ich mich Wirecard anschliessen. ;)

Was mir im Issue noch nicht ganz klar geworden ist? Sind davon auch Seiten betroffen, die aus dem Public Cache/Servercache von Contao ausgeliefert werden können?

Zitat:

---

Zitat von tab

Was mir im Issue noch nicht ganz klar geworden ist? Sind davon auch Seiten betroffen, die aus dem Public Cache/Servercache von Contao ausgeliefert werden können?

---

Vermutlich nur zu einem weitaus geringerem Maß.

Das wäre ja immerhin noch ein Lichtblick, ich werde das mal ausprobieren. Bei vielen Seiten wird ja nicht so oft was geändert. Außerdem soll das ja bei Contao 4.9.3 nichts ausmachen, weil dann trotz eingestellter langer Cachezeit eine Seite im Cache bei Änderung erneuert wird.

Ich bin gerade dabei, einen Vergleichstest vorzubereiten. Webgo CMS Power vs. Ionos Pro vs. Netcup Webhosting 4000 vs. Uberspace 7 vs. Hostingwerk. Alle bekommen exakt die selbe Website aufgesetzt ohne Public und Shared Cache, damit auch bei jedem Aufruf die volle Dröhnung an benötigten PHP-Files gebraucht wird. Das mag ein paar Tage dauern, weil es außerhalb der normalen Arbeitszeit passieren wird. Dann will ich die Installationen über Cronjobs regelmäßig aufrufen, die Zeiten messen und protokollieren. Das noch mit mehreren Messreihen mit unterschiedlichem Zeitabstand. Um mögliche, wenn auch unwahrscheinliche Zugriffe von "Unbeteiligten" auszuschliessen möchte ich per .htaccess Zugriffe auf die eine IP beschränken. Ich hoffe, dass das dann Verfälschungen verhindert. Verbesserungsvorschläge herzlich willkommen! Ich bin mal gespannt, ob das ein aussagekräftiges Ergebnis bringt und ggf. wie es ausfällt.

Was mich an der Geschichte irritiert ist insbesondere, dass an andere Stelle bereits die netcup Webhostingpakete als recht langsam bei I/O gemessen wurden. Webgo war da deutlich schneller, sogar ohne SSD-Festplatten. Allerdings hat sich das in meinen "normalen" Ladezeiten so gut wie gar nicht nachvollziehen lassen, das sollte dann wohl der OPCache bewirkt haben. Und jetzt stelle ich hier bei der Problematik fest, dass Webgo gefühlt eher sogar besonders lange Reaktionszeiten zeigt. 20+ Sekunden sind da locker drin. Muss mir allerdings das damals zur Messung verwendete Skript nochmal anschauen. Auch wenn lesen und schreiben auf die Festplatte schnell ist, muss ja das Filesystem insgesamt noch lange nicht schnell sein.

Edit: Zudem soll zumindest noch eine Messreihe mit langen Pausen und aktiviertem Public Cache durchgeführt werden.

Hallo tab,

das Ergebnis Deiner Messung würde mich auch sehr interessieren. Ich habe nämlich ein ähnliches Problem mit einem Kunden-Projekt. Ich habe auch schon Stunden in Performance-Tests investiert und auch schon eine Test-Installation bei einem anderen Hoster (netcup Webhosting 8000) aufgesetzt.

Core Web Vitals zeigt mittlerweile fast alle Seiten als zu langsam an. Ich habe jetzt den Shared Cache auf 30 Tage gesetzt und hoffe, dass es besser wird. Auch der TTFB liegt selbst bei Seiten aus dem Cache bei 3-4 Sekunden.

Wenn ich alle Module und Artikel im Layout deaktiviere liegt der TTFB bei 1 Sekunde. Ich dachte immer der TTFB hat nichts mit den Inhalten zu tun, sondern mit dem ersten Byte, der vom Server gesendet wird. Wenn die Seiten aus dem Cache ausgeliefert werde, dürfte es doch eigentlich gar nicht zu diesen Abweichungen kommen.