Performance/ TTFB Metamodels 2.1/ Contao 4.4 - Wovon hängt es ab?

Hallo zusammen,

eine Seite, die eine Metamodelliste ausgibt, hat Performance-Probleme. Daher mache ich gerade Messungen auf verschiedenen Servern.

Server 1: TTFB 10s
Server 2: TTFB 4s
Server 3: TTFB 20s

Halbiere ich die Anzahl der zu ladenden Daten, halbiert sich auch in etwa die TTFB.

Alle drei Server laden alle anderen Contao-Seiten, in denen keine Metamodels im Einsatz sind, relativ schnell. Natürlich unterschiedlich schnell. Aber zwischen 200ms und 600ms.

Frage 1:
Könnt Ihr mir sagen, von welcher "Schraube" des Servers diese Performance abhängt?
Woran kann man drehen, damit die TTFB besser wird?

Frage 2:
Im Zusammenhang mit Contao 4.4 und Cache habe ich öfter hier aufgeschnappt, dass einige Cronjobs (?) einsetzen, um regelmäßig das Cashen zu initiieren. Wie kann ich sowas machen?

Vielleicht mache ich auch einen Fehler bei den Einstellungen. Aber wenn ich gar keine Cachezeit festlege, scheint Contao die Seiten ohne Cache zu laden. Ich kann ja nur über die Cachezeiten den Cache grundsätzlich einstellen und dann immer nur für begrenzte Zeit, oder?

Vielen Dank!

Falls du Cache Warming haben möchtest, könntest du auf Contao 4.9 aktualisieren. Dort kannst du den HTTP Cache vom Crawler für alle Seiten warmen lassen.

Ist "Cache Warming" das, was einige als Notbehelf zurzeit mit Cron Jobs erledigen?

Das weiß ich nicht was andere mit Cronjobs machen ;). Das Cache Warming mit dem Crawler würdest du aber auch mit einem Cronjob machen.

Zitat:

---

Das weiß ich nicht was andere mit Cronjobs machen .

---

:-)

Ok, für 4.9 ist das erstmal gut zu wissen. Ich hatte da auch schon einiges über htaccess-Einstellungen gelesen.
Momentan ist es aber erstmal eine 4.4.

Das eigentliche Problem (Frage 1) ist die Performance ohne Cache.
Oder ändert sich das mit Metamodels 2.2 auch signifikant?

Der Redakteur dreht momentan am Rad, wenn er bei jeder Änderung 20 Sekunden auf das Laden der Website warten muss.
Zurzeit stehen die Metamodels deswegen auf der Abschussliste. Ich würde dem Hoster gerne sagen, woran er drehen muss.

Zur Performance mit MetaModels kann ich nichts sagen. Über den Symfony Profiler könntest du überprüfen ob bspw. die Datenbank Abfragen die meiste Zeit benötigen.

Zitat:

---

Über den Symfony Profiler könntest du überprüfen ob bspw. die Datenbank Abfragen die meiste Zeit benötigen.

---

Ah, interessant...
Dafür muss ich den Debug-Modus aktivieren, richtig?
Wie mache ich das...? Im Contao Manager steht "von deiner Contao-Version nicht unterstützt"...

Korrekt, ja. Im Handbuch stehen die verschiedenen Varianten, wie du den Debug-Modus benutzen kannst.

D.h. wenn der Debug-Modus von meiner Contao-Version nicht unterstützt wird, kein Symfony-Profiler?

Den Debug-Modus gibt es auch für Contao 4.4. Siehe wie gesagt das Handbuch ;)

Ok, es ist auf jeden Fall schon mal schön zu wissen, dass man ab 4.5 auch den Debug-Modus über den Contao-Manager aktivieren kann. Da ich das jetzt noch nicht kann und laut Handbuch über die Konsole ein Passwort vergeben muss, bin ich an der Stelle leider verloren.

Zitat:

---

Zitat von pipkin

Da ich das jetzt noch nicht kann und laut Handbuch über die Konsole ein Passwort vergeben muss, bin ich an der Stelle leider verloren.

---

In wie fern?

Ich habe keine Ahnung, wie man die Konsole benutzt :o:o:o

Einfach das Kommando wie beschrieben eingeben ;). Du kannst es auch in deiner lokalen Entwicklungsumgebung machen und dann die erzeugte .env Datei auf den Server kopieren.

Was ich z.B. per Cronjob mache ist, dafür zu sorgen, dass die zu Contao gehörenden PHP-Skripte im OPCache bleiben bzw da wieder reinkommen. Dazu rufe ich einfach irgendeine zugehörige Webseite per Cronjob auf. Wenn gleichzeitig zu der langen Ladezeit aber andere Seiten der selben Installation schnell ausgeliefert werden, dann tippe ich aber eher auf andere Probleme. Mach in jedem Fall erst mal das, was Spooky geschrieben hat. Dann weisst du, ob es an den Datenbankabfragen liegt. Sind denn die drei Server Shared Hosting oder (v)Server, die unter deiner/eurer Kontrolle stehen?

Zitat:

---

Einfach das Kommando wie beschrieben eingeben . Du kannst es auch in deiner lokalen Entwicklungsumgebung machen und dann die erzeugte .env Datei auf den Server kopieren.

---

Leider habe ich keine lokale Entwicklungsumgebung und bin direkt auf dem Server.
Wo genau gebe ich das Kommando ein? Ich brauche doch bestimmt irgendeine Anwendung dafür...?

Du musst dich per SSH auf den Server verbinden, unter Windows kann man dafür z.B. putty verwenden.

Zitat:

---

Sind denn die drei Server Shared Hosting oder (v)Server, die unter deiner/eurer Kontrolle stehen?

---

Zwei Shared-Hosting-Anbieter und ein dedizierter Server (Ziel-Server), auf den ich aber keinen weiteren Zugriff habe.
Einer der Shared-Hoster, Domainfactory, liefert eine Performance von 4 Sekunden, während der dedizierte Server im Schnitt 17 Sekunden braucht.

Ich habe über PHPmyAdmin zumindest auch eine direkte SQL-Abfrage vergleichen können.
Domainfactory: 0,0025 Sekunden
Dedizierter Server: 0,0003 Sekunden

Was das genau bedeutet, weiß ich aber nicht. Nur dass die Datenbank an sich schneller ist.

Zitat:

---

Du musst dich per SSH auf den Server verbinden, unter Windows kann man dafür z.B. putty verwenden.

---

SSH-Zugriff habe ich leider nicht... ich schau mal, ob ich das einrichten kann auf einem der Shared-Hoster.

Könnte ich am Mac auch was mit dem Terminal werden...?

Zitat:

---

Zitat von pipkin

:-)

Ok, für 4.9 ist das erstmal gut zu wissen. Ich hatte da auch schon einiges über htaccess-Einstellungen gelesen.
Momentan ist es aber erstmal eine 4.4.

Das eigentliche Problem (Frage 1) ist die Performance ohne Cache.
Oder ändert sich das mit Metamodels 2.2 auch signifikant?

Der Redakteur dreht momentan am Rad, wenn er bei jeder Änderung 20 Sekunden auf das Laden der Website warten muss.
Zurzeit stehen die Metamodels deswegen auf der Abschussliste. Ich würde dem Hoster gerne sagen, woran er drehen muss.

---

Für das Verhalten kann es mehrere Ursachen geben - wenn die TTFB so sehr schwanken, könnte es ein Zeichen auf DB sein... insbesondere bei Kandidaten wie 1und1/IONOS und Strato

Bei MM 2.1 gibt es einen Bug wenn für die Attribute eigene Templates erstellt wurden - dann dauert die Suche nach dem "Schwestertemplate *.text" zu lange... einfach das Template mit selben Namen anlegen und .text anhängen statt html5 (in MM 2.2 gefixt)

Bei langen Listen kann das "Prerendering" zu HTML5 sehr speicherintensiv sein - Abhilfe: Paginierung und/oder Rendering im Template machen (letztens damit eine Seite von 25Sec auf 1,4Sec beschleunigt)


PS: und Caching ist natürlich auch ein Trick... das läuft in C4.9 + MM 2.2 recht gut - MM 2.2 untersützt die ESI-tags, d.h. die Ausgabe wird bei Änderungen der Items frisch ausgeliefert

Zitat:

---

Zitat von pipkin

SSH-Zugriff habe ich leider nicht... ich schau mal, ob ich das einrichten kann auf einem der Shared-Hoster.

---

Welcher Hoster?

Zitat:

---

Zitat von pipkin

Könnte ich am Mac auch was mit dem Terminal werden...?

---

In deiner lokalen Entwicklungsumgebung, ja. Und damit kannst du dich mit dem ssh Kommando auch per SSH auf den jeweiligen Server verbinden.

Zitat:

---

Zitat von pipkin

SSH-Zugriff habe ich leider nicht... ich schau mal, ob ich das einrichten kann auf einem der Shared-Hoster.

Könnte ich am Mac auch was mit dem Terminal werden...?

---

Ja, am Mac kannst du zur Verbindung zum Server per SSH das Terminal verwenden und brauchst kein zusätzliches Programm.

Zitat:

---

Zitat von pipkin

Der Redakteur dreht momentan am Rad, wenn er bei jeder Änderung 20 Sekunden auf das Laden der Website warten muss.

---

=> geht also eher um das Backend?

Zitat:

---

Welcher Hoster?

---

Domainfactory...
Ich lese mir besser erstmal an, wie man mit SSH umgeht... :-)
(Ja, ich weiß, klaffende Wissenlücken....)

Zitat:

---

Zitat von pipkin

Domainfactory...
Ich lese mir besser erstmal an, wie man mit SSH umgeht... :-)
(Ja, ich weiß, klaffende Wissenlücken....)

---

Siehe zB https://www.df.eu/de/support/df-faq/...e-zugriff/ssh/

Zitat:

---

Für das Verhalten kann es mehrere Ursachen geben - wenn die TTFB so sehr schwanken, könnte es ein Zeichen auf DB sein... insbesondere bei Kandidaten wie 1und1/IONOS und Strato

---

Die TTFBs sind je Server recht stabil. Interessanterweise ist das kleine 9,90-Paket bei Domainfactory schneller (4 Sekunden) als der dedizierte Server (17 Sekunden). Ich hätte eher erwartet, dass er schneller ist als ein kleines Hosting-Paket. Die genauen Werte kenne ich da leider nicht (RAM usw.). Der Ansprechpartner dort sieht die Performance zurzeit nicht als sein Problem.

Zitat:

---

Bei MM 2.1 gibt es einen Bug wenn für die Attribute eigene Templates erstellt wurden

---

Ok... damit könnte ich die Voraussetzungen natürlich allgemein verbessern, erklärt aber nicht, warum es auf dem Zielserver so mau läuft im Vergleich mit Domainfactory. Dennoch: sind das konkrete Metamodel-Templates oder bezieht sich das auf alle metamodell-Templates? Ich bin bei den Template-Bezeichnungen leider nicht so im Bilde. Scheint mir hier aber der sinnvollste nächste Test zu sein...!

Zitat:

---

Bei langen Listen kann das "Prerendering" zu HTML5 sehr speicherintensiv sein - Abhilfe: Paginierung und/oder Rendering im Template machen (letztens damit eine Seite von 25Sec auf 1,4Sec beschleunigt)

---

Paginierung macht layout-bedingt nicht viel Sinn, aber Prerendering klingt interessant. Wie mach ich sowas...? Ist damit statisches HTML im Template gemeint?

Zitat:

---

=> geht also eher um das Backend?

---

Nein, geht ums FrontEnd. Der Redakteur macht Änderungen und will die Ergebnisse im FrontEnd sehen, Website neu laden etc.

Zitat:

---

Zitat von pipkin

Die TTFBs sind je Server recht stabil. Interessanterweise ist das kleine 9,90-Paket bei Domainfactory schneller (4 Sekunden) als der dedizierte Server (17 Sekunden). Ich hätte eher erwartet, dass er schneller ist als ein kleines Hosting-Paket. Die genauen Werte kenne ich da leider nicht (RAM usw.). Der Ansprechpartner dort sieht die Performance zurzeit nicht als sein Problem.

---

Dass der Ansprechpartner die Performance des von ihm administrierten Servers nicht als sein Problem ansieht ist natürlich bedauerlich. Zumal wenn ein ganz normales Webhostingpaket die gleiche Arbeit in einem Viertel der Zeit macht wie sein Server. Also Fakten sammeln (Debugmode/Profiling, PHP Konfiguration (phpinfo) abgleichen mit https://docs.contao.org/manual/de/pe...nce/php-setup/, ...), mit dem schnelleren Webhosting vergleichen und ggf den Ansprechpartner mit den entsprechenden Daten und Vergleichsdaten aus dem Webhosting versorgen.

Hmm...
Habe jetzt einen SSH-Zugang und es sogar geschafft, mich zu verbinden.
Ich bekomme diese Fehlermeldung:

Code:

---

(12:44:42) [pfad entfernt] vendor/bin/contao-console contao:install-web-dir --user=meinuser --password
X-Powered-By: PHP/4.4.9
Content-type: text/html

<br />
<b>Parse error</b>:  syntax error, unexpected T_STRING, expecting T_CONSTANT_ENCAPSED_STRING or '(' in <b>/pfad-entfernt/vendor/contao/manager-bundle/bin/contao-console</b> on line <b>12</b><br />

---

Was mag das 4.4.9 da wohl bedeuten?
PHP-Version ist 7.2...

Zitat:

---

Zitat von pipkin

A: sind das konkrete Metamodel-Templates oder bezieht sich das auf alle metamodell-Templates? Ich bin bei den Template-Bezeichnungen leider nicht so im Bilde. Scheint mir hier aber der sinnvollste nächste Test zu sein...!



B: Paginierung macht layout-bedingt nicht viel Sinn, aber Prerendering klingt interessant. Wie mach ich sowas...? Ist damit statisches HTML im Template gemeint?

---

A: jain - nur wenn individuelle Templates für die Attribute angelegt worden sind


B: MM bringt per se die Attribute vorgerendert - ist für User einfach aber nicht so performant ... schneller ist die Ausgabe als "unrendered data" und das "Rendering" im Listentemplate zu machen

Zitat:

---

Zitat von pipkin

Hmm...
Habe jetzt einen SSH-Zugang und es sogar geschafft, mich zu verbinden.
Ich bekomme diese Fehlermeldung:

Code:

---

(12:44:42) [pfad entfernt] vendor/bin/contao-console contao:install-web-dir --user=meinuser --password
X-Powered-By: PHP/4.4.9
Content-type: text/html

<br />
<b>Parse error</b>:  syntax error, unexpected T_STRING, expecting T_CONSTANT_ENCAPSED_STRING or '(' in <b>/pfad-entfernt/vendor/contao/manager-bundle/bin/contao-console</b> on line <b>12</b><br />

---

Was mag das 4.4.9 da wohl bedeuten?
PHP-Version ist 7.2...

---

Du musst noch den Pfad zur richtigen PHP Version voranstellen. Mögliche Pfade findest du hier: https://github.com/contao/contao-man.../DomainFactory

Versuche es bspw. mal mit

Code:

---

php74 vendor/bin/contao-console contao:install-web-dir --user=meinuser --password

---

Infos zu Debug: https://metamodels.readthedocs.io/de...-2-1-tips.html

Zitat:

---

A: jain - nur wenn individuelle Templates für die Attribute angelegt worden sind

---

Da sind einige Templates, die "mm_attr_..." heißen. Wären das Kandidaten dafür?
Und dann einfach neben die "mm_attr_individuell.html5" ein Duplikat "mm_attr_individuell.text" legen?

Zitat:

---

Du musst noch den Pfad zur richtigen PHP Version voranstellen.

---

Das hat jetzt zwar geklappt, aber...

Code:

---

(13:15:59) [pfad-ersetzt] php72 vendor/bin/contao-console contao:install-web-dir --user=meinuser --password
Please enter a password:13:16:58 ERROR    [console] Error thrown while running command "contao:install-web-dir --user=meinuser --password". Message: "Undefined constant 'STDIN'" ["exception" => Error { …},"command" => "contao:install-web-dir --user=meinuser --password","message" => "Undefined constant 'STDIN'"]

In QuestionHelper.php line 158:
                             
  Undefined constant 'STDIN' 
                             

contao:install-web-dir [--no-dev] [-u|--user USER] [-p|--password [PASSWORD]] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command> [<target>]

X-Powered-By: PHP/7.2.34
Set-Cookie: PHPSESSID=0f25f7badeeaa0a9493a0f0f239fceb1; path=/; HttpOnly
Content-type: text/html; charset=UTF-8

---

Zitat:

---

Zitat von pipkin

A: Da sind einige Templates, die "mm_attr_..." heißen. Wären das Kandidaten dafür?
B: Und dann einfach neben die "mm_attr_individuell.html5" ein Duplikat "mm_attr_individuell.text" legen?

---

A & B: JA

dazu gibt es auch einige Foreneinträge...

Zitat:

---

A & B: JA

dazu gibt es auch einige Foreneinträge...

---

Ja, ich hab die parallel auch "schon" entdeckt. Sorry...
Es ist halt schwierig, nach jedem wertvollen Hinweis in "Echtzeit" durchs Forum zu jagen. Grundsätzlich lese ich immer viel, bevor ich frage, tut mir leid. Es sind nur so viele spannende Ansätze gerade...

In der Testumgebung hat die Sache mit den Templates die TTFB auf jeden Fall schon mal geviertelt!! Super.....

Zitat:

---

Zitat von pipkin

Ja, ich hab die parallel auch "schon" entdeckt. Sorry...
Es ist halt schwierig, nach jedem wertvollen Hinweis in "Echtzeit" durchs Forum zu jagen. Grundsätzlich lese ich immer viel, bevor ich frage, tut mir leid.

---

war nicht als "Zeigefinger" gemeint sondern das dort ggf. noch mehr Infos dazu sind...

Ich habe nun die Attribut-Templates ergänzt durch ihre Entsprechnung mit .text und habe nun folgende Werte:

Domainfactory - vorher: 4.0 s, nachher: 1.19 s
Dedizierter Server - vorher: 18,59 s, nachher 448 ms.

Das ist ein tolles Ergebnis.

Zitat:

---

dann dauert die Suche nach dem "Schwestertemplate *.text" zu lange

---

Dann hat der dedizierte Server für diese Such-Vorgänge 4x länger gebraucht als Domainfactory ...?
Ist das dann die Geschwindigkeit der Festplatte, die vorher die Bremse war? :-)

Prima, da wird sich der Redakteur aber freuen.

Zitat:

---

Prima, da wird sich der Redakteur aber freuen.

---

:-)

Ich wüsste trotzdem sehr gerne, wo der Flaschenhals saß. Auch wenn die Suchprozesse nach Schwesterntemplates ne Weile brauchen, was dauert da 18 Sekunden, was bei DF nur 4 dauert?

Das eine ist der "Bug", das andere ist das Equipment, das nicht standhält..

Möglicherweise SSD bei Domainfactory Webhosting vs. HDD beim Server?