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:
- 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).
- 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.
Lesezeichen