Druckbare Version
Hallo zusammen,
eine C4.6.14 Installation zeigt ein merkwürdiges Verhalten: Der 1. Seitenaufruf dauert durchschnittlich 4 Sekunden, danach sind es beim Aufruf beliebger Seiten nur noch 500ms. Wenn man dann ca. 60 Sekunden wartet, braucht der nächste Seitenaufruf wieder ca. 4 Sekunden, alle anderen Seiten nur 500ms.
Es sieht so aus, als ob serverseitig nach +/- 60 Sekunden ein Cache geleert wird. Hat irgendjemand eine Idee?
An Strato kann es jedenfalls nicht liegen! Denn
Die Strato Pakete sind also praktisch sowas wie das Raumschiff Enterprise des Webhosting. Die stossen in Leistungsklassen vor, wo nie ein Hostingpaket zuvor gewesen ist. :)Zitat:
Zitat von STRATO
Da müssen wir also schon an anderer Stelle nach der Ursache suchen.
Deaktiviere mal den Frontend Cron und teste nochmal.
@spooky, kannst Du mal sagen was Du damit meinst oder wo ich den finde? in meinem Power Web habe ich nämlich keine Cron Jobs verfügbar.Zitat:
Zitat von Spooky
In den Systemeinstellungen unter Frontend-Einstellungen "Den Command-Scheduler deaktivieren".
@tab, besten Dank! soweit war ich noch gar nicht vorgedrungen. Hatte ich mich eigentlich nicht getraut, weil da im zugehörigen Text etwas vom Einrichten eines echten cronjob steht, an den ich aber im PowerWeb nicht rankomme. Hab jetzt trotzdem mal den Haken gemacht und werde mal Ladezeiten beobachten, obwohl ich damit eigentlich keine Probleme hatte, aber evtl. kommen jetzt superschnelle Ladezeiten zustande ...
Diese Cronjobs räumen eigentlich nur auf, löschen zum Beispiel alte Einträge im Log oder Ähnliches. Nichts was ein großes Problem wäre, wenn es mal einen Tag nicht gemacht wird. Nur wenn man das dauerhaft deaktiviert, muss man einen echten Cronjob dafür verwenden, diese Aufräumaktionen zu starten. Nach dem Testen halt einfach den Haken wieder rausnehmen. Den echten Cronjob müsstest du auch nicht unbedingt in deinem Powerweb Basic einrichten, das kann zur Not auch ein anderer Server übernehmen, auf dem du Cronjobs zur Verfügung hast. Es muss ja nur eine URL aufgerufen werden, das geht von überall her.
Interessanter Gedanke. Auf die Idee bin ich noch gar nicht gekommen.
Wenn es nun tatsächlich am Frontend Cron liegt - hier eine Diskussion dazu: https://github.com/contao/check/issues/134Zitat:
Zitat von VGT
Es gibt sogar Anbieter für sowas im Internet. Wie seriös derlei oft sogar kostenlose Angebote sind und was genau sie dann wirklich kosten (eventuell kein Geld, aber ... ;) ) weiss ich aber nicht. Ich habe das eine zeitlang von meinem uberspace aus mit runwhen - einer Alternative zu Cronjobs - für einige Kunden gemacht, die damals bei 1&1 waren mit Vertrag ohne ausreichende Anzahl Cronjobs.Zitat:
Zitat von mlweb
Ich habe derzeit nur einen Kunden bei Hetzner bei dem ich keinen Cronjob zur Verfügung habe, da werde ich das wohl einsetzen/testen. Alle anderen habe ich auf vernünftige Hoster umgezogen - obwohl im Moment habe ich da bei Webgo gerade meine Zweifel, aber das ist ein anders Thema.
@tab und @Spooky besten Dank für die interessanten Hinweise; Frontend Cron wieder aktiviert; mit Seitenladezeiten habe ich wie gesagt eigentlich keine größeren Probleme ...
Warum postest du dann hier? ;)Zitat:
Zitat von VGT
Das Thema habe ja ich aufgemacht und seither viel gegoogelt ... aber immer noch keine Lösung. Meine Beobachtung ist die (am besten kann man das auf einem Testsystem beobachten):
Der 1. Seitenauf dauert eine gefühlte Ewigkeit (ca. 5 Sekunden). Danach geht alles ganz flott. Erst wenn ca. 60 Sekunden kein Seitenaufruf kommt beginnt das Warten erneut. Dabei beeinflussen sich Front- und Backend gegenseitig. Auf einem V-Server ist es ganz genauso (nur sind die Warte-Zeiten etwas anders).
Meine Konfiguration: Contao 4.6.14, opcache aktiviert, keine Frontend-Cronjobs.
weil ich selbiges auch feststelle, aber andererseits nicht das große Problem sehe, wenn man mal kurz warten muss; andere sehen das evtl. andersZitat:
Zitat von Spooky
Ich habe "Command-Scheduler deaktivieren" aktiviert, das Ergebnis ist leider nicht so eindeutig, wie ich es mir erhofft hatte. Und der Debug-Modus von contao 4 bringt auch keinen Erkenntnisgewinn - SQL Query Time 44ms, Memory-Peak 14 von 256 MB, Render Time 7ms, OPcache ist aktiviert - da würde ich keinen Engpass vermuten.
Auf stark frequentierten Seiten fällt das Verhalten möglicherweise nicht soo auf. Die Seite meines "Kunden" gehört halt nicht dazu, und 5 Sekunden Warten möchte er nicht akzeptieren.
Hat irgend jemand noch eine Idee?
Habe jetzt hier im Thread ein wenig den Überblick verloren, denke aber, auf die Entwickler-Tools des Browsers haben wir noch nicht geschaut. Da müsste man doch zumindest sehen, ob die Verbindung schnell aufgebaut ist und dann das lange Warten auf das erste Byte beginnt oder womit da sonst mehrere Sekunden verbracht werden.
Wie sehen denn die Seiten so aus? Viele Datenbankabfragen und/oder Bilder? Wie sind die Cachezeiten der Seiten eingestellt? Und wie sieht es mit den Browsercache-Zeiten für die statischen Daten (Bilder, CSS, Javascript) etc aus? Hier hat die .htaccess von Contao 3 einiges mitgebracht, was in der von Contao 4 nicht mehr drin ist aber da teilweise durchaus auch Sinn machen würde.
Idee: Rufe doch die Seite zyklisch alle paar Minuten mit einem Cron ab.
Könntest Du vielleicht mal schauen, was Dir
ausgibt?Code:curl -s -w '\nLookup time:\t\t%{time_namelookup}\nConnect time:\t\t%{time_connect}\nSSL handshake time:\t%{time_appconnect}\nPre-Transfer time:\t%{time_pretransfer}\nRedirect time:\t\t%{time_redirect}\nStart transfer time:\t%{time_starttransfer}\n\nTotal time:\t\t%{time_total}\n' -o /dev/null https://example.com/
Wie sieht es denn mit der Wartezeit aus, bis der Datenbank-Server überhaupt Daten liefert, bzw. bis er reagiert und den/die/das query anfängt zu verarbeiten. Damit meine ich nicht die Query-Time. Die Angabe im Contao Debug-Tool ist mitunter trügerisch, weil die erst zählt, wenn der/die/das query beim DB-Server angekommen ist.
Ich habe festgestellt, dass bei den Raumschiff-Enterprise-Hostern, insbesondere Strato, 1&1, Mittwald... ziemlich häufig die Ladezeiten sehr langsam sind. In den Developer Tools sieht man dann, dass erstmal einfach nichts passiert (teilweise bis zu 10 Sekunden und mehr) sobald aber die DB Daten liefert, geht alles sehr schnell. Trotzdem zeigt das Contao Debug Tool schnelle Datenbank-Zugriffe.
Das Problem ist meines Erachtens, dass man keine Kontrolle über den DB-Server hat und man nie weiß, auf welchem DB-Server die Datenbank liegt. Selbst innerhalb eines Hosting-Pakets ist die Wahrscheinlichkeit gering, zwei Datenbanken auf ein und demselben Server zu erstellen. Da erkennt man schon oft Performance-Unterschiede, wenn man die Datenbank neu erstellt und sie dann auf einem andern Host liegt. Die DBs sind dann per Netzwerk angebunden, aber wenn sowohl das Netzwerk als auch der DB-Server von den vielen anderen Kunden an der Auslastungsgrenze sind gibt es ein Problem.
Ich konnte schon viele Websites beschleunigen, indem ich sie von den o.g. Hostern abgezogen und auf eigene Server gepackt habe.
@ do_while: Ich würde natürlich gerne die Ursache kennen. Auf jeden Fall wird es aber die Notlösung sein.
@ xchs: Ein Cron-Job dazu läuft bereits auf einem unbeteiligten Server. Die Auswertung kommt morgen.
@ intradesign: Wie kann ich die Datenbank -Wartezeit ermitteln?
Euch allen, auf jeden Fall schon mal besten Dank fürs Mitdenken.
Ich habe über 24 Stunden alle 15 Minuten mit curl die 'starttransfer'-Zeit ermittelt. Ob Command-Scheduler aktiviert oder deakiviert ist macht keinen signifikanten Unterschied. Und auch demo.contao.org zeigt das gleiche Verhalten: Der 1. Aufruf dauerte dort im Durchschnitt 3,8 Sekunden, die folgenden 1,9 Sekunden.
Ich kapituliere und habe den Vorschlag von do_while umgesetzt.
Hm, das kann ich aktuell nicht nachvollziehen. TTFB liegt bei mir zwischen 500 und 800 ms.Zitat:
Zitat von mPunkt
Also mein erster Aufruf von demo.contao.org hat gerade eben auch 3.4 Sekunden gedauert (TTFB), danach dann 0.4 bis 0.9 Sekunden.
Ja stimmt.
Mir fällt das allerdings auch bei eigenen Projekten manchmal auf, habe mir bis jetzt jedoch nie etwas gedacht. Vielleicht sollte man da doch ein Ticket machen.