Server oder CMS latencies?

[fr3d83]

Hi,

aktuell dikutiere ich immer ein wenig mit unserem Server Admin, woran es liegt, dass unsere Webseite immer mal höhere page load Zeiten hat.
Laut einigen Tools ist die "time to first byte" Zeit zu lang, wie er kenne ich nun, woran es liegt?

Anbei mal ein Screenshot.
Screenshot_2019-08-27 Website Speed Test Uptrends.png

VG & Danke

[Spooky]

Ist der Frontend Cron deaktiviert?

[fr3d83]

Woran sehe ich das und wenn ja, wo deaktiviere ich ihn? Was macht der überhaupt?

[Spooky]

Den Frontend Cron deaktivierst du in den System Einstellungen. Wenn du ihn deaktivierst, musst du einen echten cronjob einrichten, der /_contao/cron aufruft.

Läuft PHP auf dem Web Server über PHP-FPM?

[fr3d83]

Der Cron ist noch aktiv. Wir nutzen PHP, Server: Apache/2.4.38 (Unix) PHP/7.1.27 OpenSSL/1.0.2j-fips

[Spooky]

Ja, aber wie führt der Server PHP aus? Wenn nicht über PHP-FPM, dann sollte der Frontend Cron deaktiviert und statt dessen der richtige Cronjob eingerichtet werden.

[fr3d83]

Ok, als ich unseren Admin fragte, ob wir PHP oder PHP-FPM nutzen, meinte er PHP, kein FPM. Was muss denn der richtige Cron Job machen?

[Spooky]

Ok, als ich unseren Admin fragte, ob wir PHP oder PHP-FPM nutzen, meinte er PHP, kein FPM. Was muss denn der richtige Cron Job machen?

Die URL https://example.org/_contao/cron zB minütlich (oder zumindest stündlich) aufrufen.

Beispiel für einen crontab Eintrag:

* * * * * wget -q -O /dev/null https://example.org/_contao/cron

[tab]

Ja, aber wie führt der Server PHP aus? Wenn nicht über PHP-FPM, dann sollte der Frontend Cron deaktiviert und statt dessen der richtige Cronjob eingerichtet werden.

Ich würde eh gleich den Frontend Cron deaktivieren und den richtigen Cronjob einrichten. Schaden tut das nie. Der Effekt ist halt nur geringer, falls PHP-FPM benutzt wird. Um zu sehen, ob sich die Probleme damit bessern, kann man auch mal kurzzeitig für den Test einfach den Frontend Cron deaktivieren ohne den echten Cronjob einzurichten. Man sollte halt nicht vergessen, nach den Tests den Frontend Cron wieder zu aktivieren oder den echten Cronjob einzurichten.
Der echte Cronjob wird aufgerufen über die Route deinedomain.tld/_contao/cron

Edit: Spooky war mal wieder schneller und präziser.

[fr3d83]

Danke an euch beide, was genau macht eigentlich dieser Cron, dass er die performance verschlechtern könnte?

[fr3d83]

Also auch mit Deaktiviertem Cron, verändern sich die Werte nicht.

[tab]

Danke an euch beide, was genau macht eigentlich dieser Cron, dass er die performance verschlechtern könnte?

Der räumt praktisch die Installation auf, löscht temporäre Dateien, erzeugt die XML-Sitemap neu, löscht Suchcache, abgelaufene Tokens und ähnliches. Und löscht auch regelmäßig das System-Log. Wenn dafür kein echter Cronjob angelegt ist bzw der Frontend-Cron aktiviert ist, dann wird das am Ende jedes Requests aufgerufen und wenn das entsprechende Zeitintervall für eine Aktion abgelaufen ist, wird diese ausgeführt.

[fr3d83]

Ok, dass hat keine effekt gebracht, was kann ich denn jetzt machen, um zu sehen ob es am Server / Apache / PHP oder am CMS liegt?

[tab]

Das Wasserfalldiagramm sieht jedenfalls mal danach aus, als ob da noch kein HTTP/2 verwendet wird. Das löst aber das Problem der langen TTFB nicht, es wird ja erst weiteres Zeug runtergeladen, nachdem das erste Byte übertragen ist. Wenn das gelegentlich so lang dauert und sonst schneller ist, wird wohl Cacheing mit reinspielen. Immer wenn die Seite neu aufgebaut werden muss und nicht aus dem Cache kommt, dauert das natürlich länger.

Soweit ich dem Diagramm entnehmen kann, dauert der Aufvau der Seite wohl ca 1.5 Sekunden. Vorher sind wohl noch zwei mindestens zwei Redirects, die auch erstaunlich lang brauchen. Da kann man sicher am Server was machen und die Redirects eventuell direkt in die Apache-Konfiguration schreiben. Eventuell kann man sogar so weit kommen, dass man alles in die Konfiguration schreibt und dann keine .htaccess mehr braucht und man somit AllowOverride None setzen kann, was den Apache beschleunigen würde, so es denn einer ist. Will ich schon länger mal probieren, bin aber noch nicht dazu gekommen.

Bleiben aber immer noch die 1.5 Sekunden Seitenaufbau. Hier kann nun wieder vieles schuld sein. Server , CMS, die Seite selbst. Kann man im Debugmodus noch die Zeiten für die Datenbankabfragen sehen? Dann würde ich die mal anschauen um zu sehen, welche Anfragen die meiste Zeit verbraten. Manchmal kann ein geeigneter, zusätzlicher Index da Wunder wirken. Manchmal ist auch einfach die Datenbank lahm. PHP-Version kann auch einiges bringen, zumindest falls da noch ein PHP 5.6 genutzt wird.

[fr3d83]

Das Wasserfalldiagramm sieht jedenfalls mal danach aus, als ob da noch kein HTTP/2 verwendet wird. Das löst aber das Problem der langen TTFB nicht, es wird ja erst weiteres Zeug runtergeladen, nachdem das erste Byte übertragen ist. Wenn das gelegentlich so lang dauert und sonst schneller ist, wird wohl Cacheing mit reinspielen. Immer wenn die Seite neu aufgebaut werden muss und nicht aus dem Cache kommt, dauert das natürlich länger.

Soweit ich dem Diagramm entnehmen kann, dauert der Aufvau der Seite wohl ca 1.5 Sekunden. Vorher sind wohl noch zwei mindestens zwei Redirects, die auch erstaunlich lang brauchen. Da kann man sicher am Server was machen und die Redirects eventuell direkt in die Apache-Konfiguration schreiben. Eventuell kann man sogar so weit kommen, dass man alles in die Konfiguration schreibt und dann keine .htaccess mehr braucht und man somit AllowOverride None setzen kann, was den Apache beschleunigen würde, so es denn einer ist. Will ich schon länger mal probieren, bin aber noch nicht dazu gekommen.

Bleiben aber immer noch die 1.5 Sekunden Seitenaufbau. Hier kann nun wieder vieles schuld sein. Server , CMS, die Seite selbst. Kann man im Debugmodus noch die Zeiten für die Datenbankabfragen sehen? Dann würde ich die mal anschauen um zu sehen, welche Anfragen die meiste Zeit verbraten. Manchmal kann ein geeigneter, zusätzlicher Index da Wunder wirken. Manchmal ist auch einfach die Datenbank lahm. PHP-Version kann auch einiges bringen, zumindest falls da noch ein PHP 5.6 genutzt wird.

Danke schon einmal für die Info, PHP Version ist die 7.2. Ich werde bei gelegenheit auch von Contao 4.4.12 auf ein neues gehen.

Die Redirects in den Apache packen ist eine gute Idee, kann man das einfach so copy&paste machen oder muss man da etwas umschreiben?

Wie komme ich in den Debugmodus und wo sehe ich die DB Zeiten?

[tab]

Das sollte mehr oder minder 1:1 gehen. Wie geschrieben, ich habe das selbst noch nicht umgesetzt, aber die Idee kam mir beim Lesen dieser Seiten auf der Apache website:
https://httpd.apache.org/docs/curren.../htaccess.html
Insbesondere der Abschnitt "When (not) to use .htaccess files".

Der Debugmodus funktioniert über die Benutzung der app_dev.php. Siehe z.B. auch https://community.contao.org/de/show...311#post443311

Edit: Das Einrichten von User und Passwort geht mittlerweile auch über den Contao-Manager.

[fr3d83]

Debugmodus hat geklappt und nun?

[tab]

Jtzt sollte beim Aufruf einer Seite, z.B. per Frontend-Vorschau, ganz unten einiges an Informationen kommen, wenn man rechts unten auf den Stapel klickt kann man sich unter anderem anschauen, welche Datenbank-Queries gemacht wurden und wie lang sie gebraucht haben. Disclaimer: Das ist jedenfalls in Contao 4.7 so, habe gerade keine 4.4 zur Hand.

Edit: Naja, der "Stapel" soll eventuell Tabellenzeilen zeigen und er ist auch nicht ganz rechts, sondern das letzte der unten links ausgegebenen Icons, dahinter steht dann bei mir z.B. "41 in 21.34", also 41 Datenbank abfragen waren zum Erstekken des HTML-Codes erforderlich und sie haben insgesamt 21.34 Millisekunden gebraucht. Klickst du da mit der Maus drauf, bekommst du die einzelnen Queries und die entsprechenden Zeiten angezeigt.

[fr3d83]

Ok, kannst du hier mit etwas anfangen?
Bildschirmfoto 2019-09-04 um 15.15.06.png

[Spooky]

Ok, kannst du hier mit etwas anfangen?
Bildschirmfoto 2019-09-04 um 15.15.06.png

Klicke auf "3559 ms 106.2 MB", dann kannst du mehr analysieren.

[fr3d83]

Das wären diese optionen:
Bildschirmfoto-2019-09-04-um-15.19.41.jpg

[tab]

Sorry, mit den Symfony-Innereien kenne ich mich nicht aus. Aber die Datenbankabfragen scheinen es jedenfalls nicht zu sein, die brauchen nur 358.18 ms von 3559 ms wenn ich das richtig interpretiere.

Edit: Kann es auch nicht mit meiner Seite vergleichen, da fehlt irgendeine stopwatch Komponente von Symfony und ich will da jetzt nichts installieren, ist immerhin eine produktive Seite.

[fr3d83]

Ok, also könnte es wirklich nicht am CMS liegen?

Meine .htaccess hat insgesammt 1905 Zeilen, diese werde ich aufräumen und ein großteil den Apache übergeben.

[tab]

Wow, 1905 Zeilen ist natürlich immens viel. Hatte jetzt noch nie auch nur annähernd so viele, aber könnte mir schon vorstellen, dass das zumindest ordentlich bremst.

[Spooky]

Ok, also könnte es wirklich nicht am CMS liegen?

Doch, der Server braucht insgesamt dreineinhalb Sekunden um die Abfrage via PHP zu verarbeiten.

Da ich weiß, welche Art & Menge an Redirects du verwendest: du solltest auf dem Server für jede Domain einen eigenen VirtualHost einrichten und die Redirects - je nach Domain - dann dort direkt in der Apache Konfiguration setzen.

[fr3d83]

Guten morgen,
die allgemeinen redirects kommen jetzt in die Apache Konfiguration, was könnte man noch ändern?

[Spooky]

Ich denke du musst jemanden anheuern, der dir eine Performance Analyse macht. Möglicherweise macht dir das auch Hoster. Bei einem Shared Hosting wohl aber eher nicht. Wenn du eine große Seite betreibst, solltest du aber ohnehin kein Shared Hosting nehmen.

[fr3d83]

Das läuft alles bei uns Inhouse, die Server / VMs stehen bei uns quasi im Keller, nur der Admin sagt natürlich, dass sein System Top ist und es am CMS liegt.

[Wusch]

Was stellst du denn auf der Seite alles an? Also es wird ja einen Grund haben, warum der Controller 1,8s benötigt.

[tab]

Welches CMS würde euer Admin denn empfehlen, um die beste Performance aus eurem Top-Server herauszukitzeln? Das ist dann wohl ein echter, physikalischer Server? Ich will auch gar nicht bezweifeln, dass der Top in Schuss ist und nach allen Regeln der Kunst aufgesetzt.

[fr3d83]

Wir haben eine ganz normale copr. Webseite, mit ein paar Erweiterungen wie Sprachwechsler, Cusome Cataloge und Custome elements. Der Admin schläg sowas wie Wordpress vor.^^

[tab]

Na, da wirds dann wohl in jedem Fall noch mehr Optimierung brauchen als mit Contao . Jedenfalls ist Wordpress zumindest von Haus aus auch nicht schneller als Contao.

[Spooky]

Cusome Cataloge und Custome elements.

Das heißt es ist ein PCT Theme?

[fr3d83]

Das heißt es ist ein PCT Theme?

Nein, ist alles selber gebaut.

[Spooky]

Das läuft alles bei uns Inhouse, die Server / VMs stehen bei uns quasi im Keller, nur der Admin sagt natürlich, dass sein System Top ist und es am CMS liegt.

Es stellt ja auch niemand in Frage, ob der Server "Top" ist oder nicht. Aber der Admin sollte dir dabei helfen, das Problem zu analysieren - also herauszufinden, wo der Bottleneck ist.



Welche Module befinden sich im Seitenlayout und auf der Startseite bspw.?

[fr3d83]

Diese?
Bildschirmfoto 2019-09-06 um 11.23.06.png

Ansonsten ist Minify einschalten, Produktivmodus einschalten, Markup komprimieren und Skripte komprimieren aktiviert.

[Spooky]

Du musst, wie gesagt, analysieren, wo die meiste Zeit verloren geht. Ggf. musst du dir dabei bezahlte Unterstützung holen.