contao 🚀 - "Warmlauf" - Geschwindigkeitsprobleme Contao 4.7.X und 4.8.X | bleepcoder.com (2024)

Um auszuschließen dass es sich um ein Problem mit dem Webspace handelt könntest du ein Test-Skript nutzen um die Geschwindigkeit eines simplen PHP-Skript mit DB-Zugriff zu testen.

Z. B. /web/test.php mit folgendem Inhalt:

<?php$pdo = new PDO('mysql:dbname=NAME-DER-DATENBANK;host=127.0.0.1;port=3306', 'DATENBANK-USER', 'DATENBANK-PASSWORT', []);print_r($pdo->query("SELECT id FROM tl_content ORDER BY id LIMIT 1")->fetchObject());

Danke. Test gemacht. Folgendes Ergebnis:

• Testwebseite seit 2 Tagen nicht mehr aufgerufen (Contao 4.8.3 - Testumgebung bei All-Inkl)
• dbcheck-Script aufgerufen mit Ergebnis:
  => stdClass Object ( [id] => 1 ) 1569854018.79 <=> 1569854018.93 => 140ms!
• Contao-Frontend augerufen 20 sec!!!!! Danach wieder schnell
• dbcheck-Script erneut aufgerufen mit Ergebnis:
  stdClass Object ( [id] => 1 ) 1569854407.28 <=> 1569854407.28 => nahezu 0 ms
  stdClass Object ( [id] => 1 ) 1569854490.29 <=> 1569854490.29 => ...
  stdClass Object ( [id] => 1 ) 1569854503.02 <=> 1569854503.02 => ...

Die erste Abfrage scheint etwas länger zu sein! Aber dann geht es ja schneller, was ja auch die Folgeabfragen des Scripts zeigen! Habe das script dann sogar noch modifiziert und eine andere Abfrage gemacht mit gleichem Ergebnis:
=> stdClass Object ( [id] => 1 [tstamp] => 1505559024 ) 1569854572.63 <=> 1569854572.63

Folglich würde ich den DB-Server auschliessen oder?

Script:
<?php$start = microtime(true);$pdo = new PDO('mysql:dbname=NAME;host=localhost;port=3306', 'USER', 'PW', []);print_r($pdo->query("SELECT id FROM tl_content ORDER BY id LIMIT 1")->fetchObject());$elapsed = microtime(true);echo($start.' <=> '.$elapsed);

Folglich würde ich den DB-Server auschliessen oder?

Warum? Dein Test zeigt ja, dass selbst der einfache Query beim ersten Aufruf nach langer Zeit 140ms dauert.

Ok verstehe, aber nun habe ich fogenden Log:

Bad-Log:
[30.09.2019 16:44:24.618374] ---------- start of Script: 1569861864.6184 ----------
[30.09.2019 16:44:24.711621] ---------- start Contao: 1569861864.7116 ----------
[30.09.2019 16:44:33.908491] ---------- end Contao: 1569861876.9085 ----------

Good-Log:
[30.09.2019 16:45:36.229050] ---------- start of Script: 1569861936.229 ----------
[30.09.2019 16:45:36.231469] ---------- start Contao: 1569861936.2315 ----------
[30.09.2019 16:45:36.579915] ---------- end Contao: 1569861936.5799 ----------

Passenden Indes.php dazu:
index_debug.php.zip

Da dauern die ersten Abfragen ca. 10-30ms und letztendlich der ganze Reslitche Prozess der index.php ca. 11 sec! Beim zweiten mal um einiges schneller!

Meint ihr dass sich die DB-Abfragen von der Zeit her so aufsummieren dass es bis zu 20 Sec dauern kann? Das wäre ja wahnsinn oder? Irgendwie kann ich das fast nicht glauben da die Problematik bei Contao 3 nicht da war.
Gerne lasse ich mich überzeugen! :-)

Danke und Grüße

Meint ihr dass sich die DB-Abfragen von der Zeit her so aufsummieren dass es bis zu 20 Sec dauern kann?

Das könntest du testen indem du die SQL queries misst:

$kernel->getKernel()->boot();$kernel->getKernel() ->getContainer() ->get('doctrine') ->getConnection() ->getConfiguration() ->setSQLLogger(new class implements \Doctrine\DBAL\Logging\SQLLogger { private $start; public function startQuery($sql, array $params = null, array $types = null) { $this->start = microtime(true); } public function stopQuery() { $GLOBALS['queryTimes'][] = microtime(true) - $this->start; } });$response = $kernel->handle($request);$response->send();echo array_sum($GLOBALS['queryTimes']);

realpath_cache_size: 4096K
realpath_cache_ttl: 120

queryTimes-Script ist implementiert und wird in ein paar Stunden geliefert :-)

Schon mal danke für eure Hilfe!

Ich konnte das Verhalten ebenfalls in einer Testinstallation beobachten. Allerdings war das seinerzeit noch Contao 4.6 und die Testinstallation wurde inzwischen schon wieder gelöscht:

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/

Der selbe Aufruf unmittelbar danach:

Nun hier der Log. DB-Abfragen schauen zeitlich denke ich ganz gut aus oder?

BAD
[01.10.2019 04:11:47.608999] ---------- start of Script: 1569903107.61 ----------
[01.10.2019 04:11:47.851725] ---------- start Contao: 1569903107.85 ----------
[01.10.2019 04:11:56.391236] ---------- queryTimes: 0.700711488724 ----------
[01.10.2019 04:11:56.556546] ---------- end Contao: 1569903118.56 ----------

GOOD
[01.10.2019 04:13:03.358343] ---------- start of Script: 1569903183.36 ----------
[01.10.2019 04:13:03.360134] ---------- start Contao: 1569903183.36 ----------
[01.10.2019 04:13:03.539992] ---------- queryTimes: 0.0309433937073 ----------
[01.10.2019 04:13:03.540024] ---------- end Contao: 1569903183.54 ----------

Hier die index.php dazu:
index.php.zip

Hier noch ein Log von einem anderen Kunden bei HostEurope.
Der obige Log war bei All-inkl:

Good
[01.10.2019 04:21:06.047230] ---------- start of Script: 1569903666.0472 ----------
[01.10.2019 04:21:06.145857] ---------- start Contao: 1569903666.1459 ----------
[01.10.2019 04:21:16.911420] ---------- queryTimes: 0.13273954391479 ----------
[01.10.2019 04:21:16.911487] ---------- end Contao: 1569903678.9115 ----------

Bad
[01.10.2019 04:22:04.669430] ---------- start of Script: 1569903724.6694 ----------
[01.10.2019 04:22:04.671955] ---------- start Contao: 1569903724.672 ----------
[01.10.2019 04:22:04.857999] ---------- queryTimes: 0.0024192333221436 ----------
[01.10.2019 04:22:04.858057] ---------- end Contao: 1569903724.8581 ----------

Selbe index.php wie oben, nur halt mit anderen DB-Zugangsdaten. Ebefalls Contao 4.8.3.

wieder einer von Strato.

Bad
[01.10.2019 04:27:55.895978] ---------- start of Script: 1569904075.9 ----------
[01.10.2019 04:27:56.102346] ---------- start Contao: 1569904076.1 ----------
[01.10.2019 04:28:05.747466] ---------- queryTimes: 0.813222408295 ----------
[01.10.2019 04:28:05.747561] ---------- end Contao: 1569904085.75 ----------

Good
[01.10.2019 04:28:51.501258] ---------- start of Script: 1569904131.5 ----------
[01.10.2019 04:28:51.503348] ---------- start Contao: 1569904131.5 ----------
[01.10.2019 04:28:51.716928] ---------- queryTimes: 0.0130894184113 ----------
[01.10.2019 04:28:51.716984] ---------- end Contao: 1569904131.72 ----------

Bei allen "Schlechten" ist die Query-Time auch etwas höher, aber wenn ich den Code richtig verstehe, sind da alle Anfragen zeitlich aufsummiert! Das wäre ja dann denke ich ok oder!?

Was meint ihr?

Neben dem Umstand, dass die Differenz der Query-Times bei deinen Tests unter einer Sekunde liegt (bei Hosteurope nur eine zehntel Sekunde), habe ich diesbezüglich auch noch einen Test durchgeführt.
Dazu habe ich den Ordner einer Contao 4.8-Installation mehrfach kopiert und die Kopien unter zwei verschiedenen Subdomains bereitgestellt (mit denselben Datenbankzugangsdaten). Heute morgen war dann unter beiden Subdomains der erste Aufruf erheblich langsamer als der zweite Aufruf, obwohl die Installationen auf dieselbe Datenbank zugreifen.

Vermutlich ist daher ein Dateisystem-Cache ursächlich für diese Problematik, bzw. anders gesagt die Vielzahl der Dateizugriffe durch die Architekturänderungen in Contao 4 mit dem Einsatz von Symfony.

PS: Du kannst deine Beiträge über den Button oben rechts auch bearbeiten.

Ok das klingt für mich auch plausibel. Danke fürs Prüfen!
Kann hier von Kundenseite optimiert werden oder müsste da bei der grundsätzlichen Architektur angeriffen werden?

Es wäre so schade wenn so ein "geiles" System so eine Krücke hätte? Wir machen halt doch immer wieder Seiten, welche wenig stark frequentiert sind (z.B. Vereine oder ähnliche) und da möchte ich ungern auf Contao verzichten! :-)

Ja, habe ich jetzt auch kapiert dass man editieren kann :-)

Hi,
zu guter Letzt noch mal einen mit 20 Sec bei All-Inkl:

Bad
[01.10.2019 17:19:20.676863] ---------- start of Script: 1569950360.68 ----------
[01.10.2019 17:19:20.692875] ---------- start Contao: 1569950360.69 ----------
[01.10.2019 17:19:40.823580] ---------- queryTimes: 0.895588874817 ----------
[01.10.2019 17:19:40.823616] ---------- end Contao: 1569950380.82 ----------

Good
[01.10.2019 17:20:11.668419] ---------- start of Script: 1569950411.67 ----------
[01.10.2019 17:20:11.670156] ---------- start Contao: 1569950411.67 ----------
[01.10.2019 17:20:11.990045] ---------- queryTimes: 0.0479650497437 ----------
[01.10.2019 17:20:11.990076] ---------- end Contao: 1569950411.99 ----------

Dadie Datenbank gut aussieht scheint es wohl schon in die Richtung mit dem Dateizugriffen zu gehen wie Mynyx beschrieben hat!

Wie gehen wir hier weiter vor? Das kann man ja so nicht lassen oder?

Nochmals die Index.php :
index.php.zip

Als Sofortmaßnahme könntest du Cronjobs einrichten, der stündlich einen Aufruf durchführen. (Oder einen kostenlosen Monitoring-Service nutzen, der entsprechende Aufrufe durchführt).

Nutzt du den Contao Manager?

Bei mir taucht das Problem ebenfalls auf, und zwar bei Contao 4.4.X.
vgl. https://community.contao.org/de/showthread.php?73770-Geschwindigkeitsproblem-bei-1-amp-1-Ionos/page2&p=511357&viewfull=1#post511357

Wir haben das Problem am 24. Oktober auf Mumble besprochen. Um das Problem eingrenzen zu können, brauchen wir noch deutlich mehr Informationen.

1. Wie läuft PHP auf eurem Server? Als Apache-Prozess oder als FPM oder CGI?

Bitte führt außerdem mal folgende Tests aus (dazwischen bitte immer den einen Tag abwarten 🤷‍♂):

1. Löscht den Ordner var/cache/prod und ruft danach die Webseite auf. Wie lange dauert der Seitenaufbau jetzt?

2. Kommentiert folgende Zeile in der Datei app_dev.php aus:

https://github.com/contao/contao/blob/0236382bf085f0a210409957c4b9c70c184f810b/manager-bundle/src/Resources/web/app.php#L33

Tritt das Problem noch auf?

1. Löscht sämtliche Erweiterungen außer dem Contao-Core. Tritt das Problem noch auf?

Eine vergleichbare Problematik tritt übrigens auch bei Symfony Standardinstallationen auf. Im Performance-Bereich des Profilers ist dann beim ersten Aufruf auch in der Timeline zu beobachten, dass alle Vorgänge deutlich länger benötigen.

Wie hoch die Verzögerung jeweils bei einer Symfony Standardinstallation und bei Contao auf demselben Server ist, habe ich jedoch bisher nicht getestet.

@ xprojects-de @Aybee @webaffin @webathlet @Shoekrates @jaennert @tixtrix https://github.com/contao/contao/issues/809#issuecomment -545936523

Können wir mal die Erweiterungen bei betroffenen Installation abgleichen?

• Datenbanksicherung
• jrgregory/m17-sticky-backend-footer
• RockSolid Columns
• RockSolid Custom Elements
• RockSolid Icon Picker
• RockSolid Slider

Diese sind bei den bei mir betroffenen Installationen neben dem Bundle im Einsatz.

Meine Umgebung:

• 1&1 IONOS SE, PHP-Binary in /usr/bin/php7.3-cli
• CGI/FastCGI / PHP Version 7.3.11
• Contao 4.4.45

Meine Erweiterungen:

• alnv/catalog-manager
• delahaye/dlh_googlemaps
• do-while/contao-backupdb-bundle
• RockSolid AntiSpam
• RockSolid Columns
• RockSolid Custom Elements
• RockSolid Icon Picker
• RockSolid Mega Menu
• RockSolid Slider
• MultiColumnWizard
• Sprachenwechsler

Hosting bei Strato und phpWebsite.

phpWebsite schreibt:
so ich hab deinem Vertrag die OPCACHE DEAKTIVIERT.
Contao hat da ein grosses Problem, welches von den Entwicklern nciht
gefixt wird

Serverkonfiguration bei phpWebsite: /opt/php-7.2/bin/php

Pakete:
Contao Open Source CMS Bundle
ODD Theme
jrgregory/m17-sticky-backend-footer
RockSolid AntiSpam

Am 20.11.2019 um 11:23 schrieb Leo Feyer [emailprotected]:

@xprojects-de https://github.com/xprojects-de @Aybee https://github.com/Aybee @webaffin https://github.com/webaffin @webathlet https://github.com/webathlet @Shoekrates https://github.com/Shoekrates @jaennert https://github.com/jaennert @tixtrix https://github.com/tixtrix #809 (comment) https://github.com/contao/contao/issues/809#issuecomment-545936523
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/contao/contao/issues/809?email_source=notifications&email_token=AKMU6QW2RC7PRA5KTYMYYILQUUFZJA5CNFSM4I3Z7TB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEERPMRQ#issuecomment-555939398, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMU6QVJCE3QPBNMXR4TMMTQUUFZJANCNFSM4I3Z7TBQ.

2 x Contao 4.4.45 inkl. allen Sub-Paketen (News bis Auflistung) auf unterschiedlichen Hostings bei webgo mit offiziellen Demo-Inhalten (4.0.0) sind eingerichtet.
Einmal OPcache aktiviert auf Hosting #1 Debian 4.9.65 & MariaDB und einmal ohne auf Hosting #2 Debian 4.9.189-3 MySQL.
Beide:

• PHP Version 7.3.11
• Contao Manager 1.2.1
• Hinter Basic Auth
• Eingerichtet über Subdomain

Beide Seiten laufen im Frontend & Backend normal.

Auf dem Hosting #1 mit aktiviertem OPCache ist auch das erwähnte Problem-System installiert, derzeit mit täglichem Cron in der Nacht zur Wahrung der Lauffähigkeit.

Nächster Bericht in 24h+

Gibt es schon erste Ergebnisse?

Der Erststart dauert gefühlt unendlich lang und so kann ich die Seite nicht an den Verein geben.

Gibt es schon erste Ergebnisse?

Bisher gibt es nur Beobachtungen.

Ja, "gerade" ausgeführt, nach oben erwähnten Facts. Werte sind aus Firebug via Firefox Developer
Edition.

• Debian 4.9 / Apache 2
• PHP Version 7.3.11 als _CGI/FastCGI_
• Contao 4.4.45 mit Demo Inhalten
• Contao Manager 1.2.1
• Hinter Basic Auth
• ionCubeLoder aktiv v10.3.4
• Let's Encrypt SSL installiert, mod_ssl/2.4.25, OpenSSL/1.0.2t
• _nginx als ReverseProxy_ (LoadBalancer)
• Eingerichtet über Subdomain contao-demo.domain.tld
• Hosting #1 mit OPcache & MariaDB (vorheriger Problemfall entedeckt)
• Hosting #2 ohne OPcache & MySQL

Testfall 1 vom 22.11. 12:52 Uhr - nach Installation hinter Basic Auth und (über) einem Tag warten:
(leider hier ohne Einzelwerte zu Ladezeit des document)

Erstaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

4,08 Sekunden / load

1. webgo Hosting #2 ohne OPcache
   21,37 Sekunden / load

_Auszug access.log webgo hosting #2_ bzgl. 12:52:20 Erstaufruf > 12:52:20, nächste Ladezeit CSS-File 12:52:41

[22/Nov/2019:12:52:20 +0100] "GET / HTTP/1.0" 401 381 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0" contao-demo.domain.tld x.x.x.x - BenutzernameBasicAuth [22/Nov/2019:12:52:41 +0100] "GET /assets/css/16c83342e203.css HTTP/1.0" 200 49334 "https://contao-demo.domain.tld/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0" contao-demo.domain.tld

Zweitaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

896ms / load

1. webgo Hosting #2 ohne OPcache
   800ms / load

Testfall 1b vom 22.11. 12:57 Uhr - Leeren des Prod-Cache via Contao Manager

Erstaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

1,88 Sekunden (1291ms bei document) / load

1. webgo Hosting #2 ohne OPcache
   4,03 Sekunden (3591ms bei document) / load

Zweitaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

629 ms (162ms bei document) / load

1. webgo Hosting #2 ohne OPcache
   722 ms (208ms bei document) / load

_Kommende Testfälle_
Testfall 2 - Prod-Cache via Contao Manager leeren, Ergebnisse dann 24h+

Testfall 3 - ContaoCache deaktivieren via Uncomment app_dev.php, Ergebnisse dann ~ 72h+

Hallo zusammen,

erstmal danke fürs Testen und den Einsatz! Finde ich super!

Auf Anfrage von Andreas Schempp habe ich schon vor ca. 3 Wochen ein Account mit allen gewüschnten Zugängen und einer Contao 4.8.4 Installation mit lediglich/nur dem "Contao 4 manager bundle" bei All-Inkl zur Verfügung gestellt. Sonst keine weiteren Erweiterungen installiert!
Bis dato habe ich noch keine Rückmeldung von Adreas Schmepp bekommen.

Info zur Seite:

• Nur Contao 4 manager Bundle installiert
• Keine Inhalte (Leere Artikel) und nur Startpunkt und eine Startseite
• Keine Stylesheets, Bilder oder sonst irgendwelche Inhalte -> leere Seite!
• Kein OPCache

Habe eben selber einen Test gemacht:

1. Aufruf: 10.92s
2. Aufruf: 321ms ohne Eingriff
3. Aufruf: 250ms nachdem Prod-Cache erneurt wurde
4. Aufruf: 650ms /var/cache/prod gelöscht und Prod-Cache nicht erneuert wurde

Werde morgen noch mal den ContaoCache auskommentieren!

Hoffe es hilft!

Danke und Grüße

Hi zusammen. Nach einem für die Familie reservierten WE hier nun die neuen "Ergebnisse".

Aktualisierte Zusammenfassung der Hosting-Grundlage, wie auch oben aktualisiert.

• Debian 4.9 / Apache 2
• PHP Version 7.3.11 als _CGI/FastCGI_
• Contao 4.4.45 mit Demo Inhalten
• Contao Manager 1.2.1
• Hinter Basic Auth
• ionCubeLoder aktiv v10.3.4
• Let's Encrypt SSL installiert, mod_ssl/2.4.25, OpenSSL/1.0.2t
• _nginx als ReverseProxy_ (LoadBalancer)
• Eingerichtet über Subdomain contao-demo.domain.tld
• Hosting #1 mit OPcache & MariaDB (vorheriger Problemfall entedeckt)
• Hosting #2 ohne OPcache & MySQL

Testfall 2 vom 25.11. 09:14 Uhr - Prod-Cache via Contao Manager vorab leeren und nach 24h Inaktivität erneuter Aufruf, Ergebnisse

Erstaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

8,49 s (~ 4,5 s bei document) / load

1. webgo Hosting #2 ohne OPcache
   15,31 s (~ 13,5 s bei document) / load

Zweitaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

613 ms (489ms bei document) / load

1. webgo Hosting #2 ohne OPcache
   841 ms (773ms bei document) / load

Umgekehrt bin ich dazu einer Fragestellung nachgegangen, welche "Hosting-Komponente" denn nach exakt 24h Inaktivität sich erneueren muss und nach Ausschluss von ioncube, zend, opcache, apache bin ich beim nginx als ReverseProxy hängen geblieben.

Recherchierte Vermutungen als mögliche Beweisumkehr:
Nginx als Reverse Proxy enthält eine Lease für den Cache von einem Tag
https://www.nginx.com/resources/wiki/start/topics/examples/reverseproxycachingexample/
proxy_cache_valid 200 1d;

Hätte hier jemand Zeit und direkten Einfluss den ProxyCache einmal diesbezüglich zu purgen?

https://www.ryadel.com/en/nginx-purge-proxy-cache-delete-invalidate-linux-centos-7/

Schönen Wochenstart allerseits!

Testfall 3 vom 26.11. 17:18 Uhr - ContaoCache in app.php auskommentieren und nach 24h Inaktivität erneuter Aufruf, Ergebnisse

Ein etwas seltsames Ergebnis beim Erstaufruf zum gesamten Dom-Load, da der Aufruf gestartet und erst später (~1min) der Basic-Auth mit vorausgefüllten Login credentials zeitnah hintereinadner bestätigt wurde. Zuerst wurde Fenster mit Hosting #2 und danach direkt mit Hosting #1 geklickt. Der document-load dürfte hier entscheidend sein.

Erstaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

1,05 s (~ 5,6 s bei document) / load

1. webgo Hosting #2 ohne OPcache
   58,34 s (~ 2,4 s bei document) / load

Zweitaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

496 ms (300ms bei document) / load

1. webgo Hosting #2 ohne OPcache
   977 ms (553ms bei document) / load

Vermutung #2 - Basic Auth mit komplizierten Hashes nagen mit an der Performance
https://discourse.haproxy.org/t/basic-authentication-causes-massive-drop-in-performance/2654
https://www.webperformance.com/load-testing-tools/blog/2011/06/how-http-authentication-works-and-why-load-testers-should-care/

Der Test wird morgen wiederholt ...

Basic Auth mit komplizierten Hashes nagen mit an der Performance

Das erklärt aber nicht den krassen Unterschied von 1,05s zu 58,34s beim Erstaufruf.

Basic Auth sorgt aber dafür, dass Contao immer ein CSRF-Cookie setzen muss, somit kannst Du nur entweder den .htaccess-Schutz oder den HTTP-Cache nutzen.

https://github.com/contao/contao/blob/c8924544c8e4eab7e970bee923b731bcb1e0212d/core-bundle/src/EventListener/CsrfTokenCookieListener.php#L86-L88

Basic Auth mit komplizierten Hashes nagen mit an der Performance

Das erklärt aber nicht den krassen Unterschied von 1,05s zu 58,34s beim Erstaufruf.

Basic Auth sorgt aber dafür, dass Contao immer ein CSRF-Cookie setzen muss, somit kannst Du nur entweder den .htaccess-Schutz oder den HTTP-Cache nutzen.

https://github.com/contao/contao/blob/c8924544c8e4eab7e970bee923b731bcb1e0212d/core-bundle/src/EventListener/CsrfTokenCookieListener.php#L86-L88

Ich würde die 59sec eher auf einen Bug in Sachen Firefox vs. Firebug vs. "Ich geh mal eine Runde nach den Kindern gucken" schieben, denn nach Bestätigung der vorausgefüllten Credentials, waren die Seiten mit einem Flupp da. Korrekt ist daher der load des documents zu werten.

Aber auch das erklärt das nicht. Also jede Seite sollte wohl auch ohne HTTP Cache in vernünftiger Zeit laden.

Sicherlich. Die Tests wiederhole ich dann generell noch ohne Basic Auth. Diese Tests hier führe ich mit Basic Auth aus, weil diverse andere Erfahrungsberichtende dieses Phänomen wie ich vorallem hinter Basic Auth und Subdomain ohne jegliche aktivierten Browser/Systemcache beobachtet haben.
Beobachtet habe ich dennoch das Phänomen auch beim Produktivmodus einen Tage bei einem 1&1-Paket ohne Basic Auth. Lösung hier war auch der cron.

Allerdings sind die „PHP ohne OPcache“-Vergleiche nicht wirklich wertvoll, weil das darf nun wirklich nie vorkommen in Production.

Warum das? Es geht hier um den Erstaufruf, sei es Aufruf des Frontend- oder Backend-Index. Denn solange das System, wie es scheint "warm" bleibt und nicht unter die Zeit x Inaktivität fällt, gibt es das Problem nicht. Oder etwa doch? Und ist Zeit x tatsächlich exakt 24h?

Mich wundert nur, dass sich das mit aktiviertem OPCache auf dem gleichen System nicht derart in den Ergebnissen wiederspiegelt, wie mit einem ähnlichen in Entwicklung befindlichen gleichen System zwei Ordner nebenan. Ist es also die Masse an Dateien, oben drauf, die es bei realen Projekten mehr gibt und irgendwelche Limits (files, write actions, cache timeouts) ausreizt? Ich bin leider nicht tief genug im Thema der Programmierung, sehe aber derzeit keine relevanten Werte mit 24h/1d.

(Generell, konnte ich das Problem auch nicht nur bei webgo, sondern diversen anderen Hostern beobachten. Und dabei waren auch wirklich gut aufgestellte Systeme und nicht nur Massenhoster/Shared Hostings.)

Ähnliche Probleme?
https://github.com/googleapis/google-cloud-php/issues/819

Dem kann ich mich nur anschliessen.
Ich habe das Verhalten sowohl bei Servern mit OpCache (1und1 und Strato) sowie auch ohne OpCache (Allinkl Pakete ohne SSD). Wie @webathlet schreibt ist das System im "warmen" Zustand ja performant, auch ohne OpCache!
Die 24h sind nicht belastbar! Ich habe bei manchen System das Verhalten schon nach 4-5h oder gar schneller (Strato)! Mir scheint es auch so zu sein, dass es mit beispielsweise mehr installierten Extensions schlimmer wird, was wiederum für die Masse an Dateien sprechen würde! Aber warum ist es dann danach performant?

Die Performanceproplematik kam erst mit Contao4! Die 3er Versionen laufen und liefen auf allen besagten Server mit gleichem PHP. etc. wie ein "Wiesel" mit mega schnellen Antwortzeiten!

Wiederholung Testfall 3 vom 27.11. 19:10 Uhr - ContaoCache in app.php auskommentieren und nach 24h Inaktivität erneuter Aufruf, Ergebnisse

Erstaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

4,48 s (~ 3,7 s bei document) / load

1. webgo Hosting #2 ohne OPcache
   1,5 s (~ 1,62 s bei document) / load

Zweitaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

922 ms (321ms bei document) / load

1. webgo Hosting #2 ohne OPcache
   1,13s ms (780ms bei document) / load

Zur Info:
webgo Hosting #2 hat keine früheren Aufrufe des Systems gehabt unter der Subdomain in dem unterliegenden Verzeichnis, jedoch gestern habe ich einige weitere Tests zu späteren Stunde vorgenommen, Duplikate dieses Systems inkl. Datenbank-Klon auf weitere Nebenverzeichnisse mit anderen Subdomains getestet, um mit dem gleichen Datenbestand die Symptome zu provozieren, was nicht gelang.

Vermutung:
Ein vorgelagerter Cache verursacht nach Erneuerung in Kombination mit dem C4 ContaoCache den Performance-Lag.

(Ins Blaue gedacht: Psr6 write actions & standard prune limit vs. nginx bzgl. file hash & last modify header)

Wiederholung des Tests 48h+

Das erinnert mich an ein Problem, dass wir auf contao.org hatten. Dort waren alle Requests, bei denen Cache-Tags bereinigt wurden, sehr langsam und haben die CPU extrem belastet.

@Toflar hat das damals sehr detailliert untersucht: contao/contao#606

@webathlet Kannst Du nachvollziehen, wie viele Dateien und/oder Symlinks im Ordner var/cache/prod/http_cache liegen, wenn das Problem auftritt?

Wiederholung Testfall 3 vom 29.11. 22:32 Uhr - ContaoCache in app.php auskommentieren und nach 24h Inaktivität erneuter Aufruf, Ergebnisse

Erstaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

13,81 s (~ 9,8 s bei document) / load

1. webgo Hosting #2 ohne OPcache
   28,44 s (~ 25 s bei document) / load

Zweitaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

942 ms (458ms bei document) / load

1. webgo Hosting #2 ohne OPcache
   7,57s ms (7s bei document) / load

Drittaufruf Frontend-Index:

1. webgo Hosting #1 mit aktiviertem OPcache

558 ms (138ms bei document) / load

1. webgo Hosting #2 ohne OPcache
   1,39s ms (882ms bei document) / load

Das erinnert mich an ein Problem, dass wir auf contao.org hatten. Dort waren alle Requests, bei denen Cache-Tags bereinigt wurden, sehr langsam und haben die CPU extrem belastet.

@Toflar hat das damals sehr detailliert untersucht: #606

@webathlet Kannst Du nachvollziehen, wie viele Dateien und/oder Symlinks im Ordner var/cache/prod/http_cache liegen, wenn das Problem auftritt?

@leofeyer
0 / Ordner ist nicht angelegt bei Testfall 3
var/cache/prod/ enthält 329 files / 447 gesamt

Das von mir erwähnte Dev-System mit der Problematik hat derzeit in prod-cache
1725 files / 2362 gesamt
und 0 in http_cache

Ich bin mir ziemlich sicher, dass das Problem nicht bei Contao liegt. Ich kann keine solchen Probleme feststellen und habe Antwortzeiten < 50ms im Schnitt.

@Toflar
Geht es hier nicht um die beobachtete Problematik des Erstaufruf nach langer Inaktivität bzgl. eines warm up?

Nach heutigen Zahlen und Vergleichen lässt sich für mich kein ableitendes Muster erkennen um die Symptomatik einordnen zu können. Erstaufruf von #1 auf einmal höher als gewohnt - Zweitaufruf bei #2 mit Lag. Da müssen wohl test cases her.

Von diesen weiteren, nicht zwingend objektiven Zahlenerhebungen sehe ich mangels Hinweisen oder Einblicke in Logs oder dahinter liegenden Infrastrukturen ab.

Ich kann ebenfalls kein Muster erkennen. Bei mir hat das auskommentieren des Caches auch nichts gebracht. Ich denke jedenfalls dass es wohl an der Kombination Symfony+Contao liegt. Ich habe interessehalber mal eine Contao3-Installation parallel auf gleichem Account mit anderer SubDomain installiert und exakt gleichen Inhalt reingepackt!
Die Startup-Probleme treten nur bei der 4er Version auf! Contao 3 ist immer gleich schnell weit unter 1 sec beim ersten Aufruf!
Ich möchte ja nicht behaupten, dass es am Code-Anteil von Contao liegt. Eventuell hat ja auch Symfony ein Problem. Aber es ist definitiv so dass das jetzige Contao 4er Setup definitiv ein Performance-Problem hat, was sich ja von vielen Seiten der Community bestätigt!

Die Aussage von @Toflar, dass es wohl nicht an Contao liegt, finde ich schade, nur weil er das Problem nicht beobachten kann. Die Community meldet hier massive Probleme seit Contao 4 und es wäre wirklich super cool wenn sich das Core-Team das genauer anschauen könnte.

Ich bin mir nicht sicher, ob dieses Ergebnis wirklich schlüssig ist.

Ich kann das oben beschriebene Verhalten reproduzieren, indem ich meinen Rechner komplett neu starte und dann eine Anfrage an eine Contao 4-Installation stelle. Die erste Anfrage nach dem Neustart dauert immer deutlich länger. Danach ist jede Anfrage so schnell wie erwartet.

Hier der Blackfire-Vergleich: https://blackfire.io/profiles/compare/28a350b1-a148-4727-ae8d-1657284bb3d7/graph

Die Verarbeitungszeit liegt laut Blackfire in der Regel bei 280 bis 285 ms, im Test, wo es erstmals länger dauert, sind es 1040 ms. _Allerdings_ ist der __aktuelle__ TTFB deutlich _länger_ als nur eine Sekunde für die erste Anfrage. Es variiert - aber es ist tatsächlich mehrere Sekunden lang, nicht nur eine Sekunde. Es sieht also so aus, als ob auch außerhalb von PHP beim ersten Mal mehr Zeit verloren geht?

Innerhalb von PHP geht laut Blackfire-Profiling die gesamte Zeit (im Vergleich zu den schnellen TTFBs) beim Laden der Klassen verloren.

Umfeld:

• Windows 10 x64
• __nginx__ 1.17.4
• __MariaDB__ 10.4.10
• __PHP__ 7.1.29
• __opcache__ _deaktiviert_
• __Contao__ 4.4.45

Composer\Autoload\includeFile() geht von 726 ms auf 143 ms. Dies könnte an Dateisystem-Caches liegen, denke ich. Oder hat PHP vielleicht eine andere Cache-Ebene für Datei-Includes außer OPCache?

_Allerdings_ ist der eigentliche TTFB deutlich _länger_ als nur eine Sekunde für den ersten Request. Es variiert - aber es ist tatsächlich mehrere Sekunden lang, nicht nur eine Sekunde. Es sieht also so aus, als ob auch außerhalb von PHP beim ersten Mal mehr Zeit verloren geht?

Um Probleme beim Starten des Webservers auszuschließen, können Sie ein test.php -Skript mit <?php echo 'test'; hinzufügen, das Sie dann vor der Anfrage an Contao selbst anfordern.

Ich habe noch ein paar Tests gemacht: https://docs.google.com/spreadsheets/d/1r6_IfBCEJts3qvMNou5s5TUjeAxPTxYgRcAf6wBPFs4/edit

Nach einem Neustart ist die erste Anfrage für die Contao 4.4.45-Installation 22-mal langsamer. _Allerdings_ ist es auch 20 mal langsamer für die Contao __3.5.40__ Installation. Ich gehe also davon aus, dass es eine Art internes Caching zu geben scheint und daher alle Webanwendungen betroffen sind, nicht nur Contao. Da ich das Problem nicht reproduzieren kann, indem ich einfach alle Dienste neu starte, gehe ich davon aus, dass es etwas vom Betriebssystem ist.

Daher kann es sein, dass das Problem, das ich hier beobachte, _nicht_ dasselbe ist wie die anderen Leute. Könnte ganz normal sein.

Auf einigen Websites unserer Kunden ist uns das Gleiche aufgefallen. Wir haben dem jedoch nicht viel Aufmerksamkeit geschenkt, da es nicht leicht reproduzierbar war und wir es nur für einen Zufall hielten. Wenn es Zeit ist, werde ich versuchen, es auch dort zu bestätigen.

Um Startprobleme des Webservers auszuschließen, könnten Sie ein _test.php_-Skript mit <?php echo 'test'; hinzufügen, das Sie dann vor der Anfrage an Contao selbst anfordern.

@ausi Das habe ich getan, aber es hatte keine Wirkung.

Die Aussage von @Toflar, dass es wohl nicht an Contao liegt, finde ich schade, nur weil er das Problem nicht beobachten kann. Die Community meldet hier massive Probleme seit Contao 4 und es wäre wirklich super cool wenn sich das Core-Team das genauer anschauen könnte.

Ich könnte genauso argumentieren, dass ich es schade finde, dass du behauptest es liegt an Contao 4 nur weil die Community "massive Probleme" meldet. Fakt ist, ich kann keinerlei Startup-Probleme beobachten, also muss ich davon ausgehen, dass etwas anderes das Problem verursacht genauso wie du davon ausgehst, dass es an Contao liegt. Und das Core-Team schaut es sich doch schon längst genauer an, es diskutieren ja fast alle mit. Aber solange es auf eigenen Systemen mit entsprechenden Debugging-Tools nicht reproduzierbar ist, können wir halt auch nicht zaubern. Wäre das Problem eindeutig identifizierbar, wäre es wohl längst behoben.

Or maybe PHP has another cache-level for file includes apart from OPCache?

Maybe because of relative path names that are cached. See the ini-directives realpath_cache_size and realpath_cache_ttl.

Wir sprechen hier über Leistung, können wir also die Tests "ohne OPcache" bitte weglassen? Sie sind nicht hilfreich. Symfony (und viele andere von uns verwendete Bibliotheken) optimieren ihre eigenen Caches für OPCode (zB erzeugen sie mehrere Dateien anstatt nur eine usw.). Damit sind sie natürlich langsamer als Contao 3.5 ohne OPCache.
Das Ausführen von PHP ohne OPCache ist einfach kein Anwendungsfall für eine Produktionssite. Und wer OPCache nicht nutzt, schadet der Umwelt und ist in keiner Leistungsdiskussion willkommen. Zeitraum.

Nun zurück zur Startzeit: Kann jemand die mtime der Cache-Dateien überprüfen? Sind sie korrekt?
Und können Sie überprüfen, ob die Konfiguration Ihrer php.ini wie folgt hilft?

; php.ini; maximum memory allocated to store the resultsrealpath_cache_size=4096K; save the results for 10 minutes (600 seconds)realpath_cache_ttl=600

Hallo zusammen,

vielleicht eine letzte Erkenntnis von meiner Seite.

Habe gerade zwei Kunden wo es das Problem fast gar nicht gibt (nur ca. 2-3 Sek. Ladezeit beim ersten Aufruf). Zum einen ist es ein Kunde, welcher tatsächlich einen eigenen Server hostet (auch physikalisch :-), mit Ubuntu-Server-Software) und der andere mit einem Powerpaket bei Mittwald.
Desweiteren sehe ich nach abgeändertem Zeitplan beim Server-Monitoring, dass speziell bei Allinkl die Erstaufrufe nachts schneller sind als unter Tags (ca. 4-6 Sek anstelle von 15-20 Sek.). Eventuell haben die Server nachts nicht so eine starke Auslastung und es ist deswegen schneller!?
Auch sieht man, dass es durchaus auch schon nach 2-3h erneut zu einer Verlangsamung kommen kann!

Vielleicht ist es wirklich so, dass Symfony einfach eine gewissen Performance des Server fordert, was halt leider zum heutigen Tag noch viele Standard-Anbieter mit Standardpaketen nicht bieten können/wollen, z.B. Strato, All-Inkl oder andere Standard-Pakete und vielleicht muss man im Moment einfach noch mit dieser Problematik leben, speziell bei kleineren Webseite mit weniger Traffic!

Gerne unterstürze ich weiter wenn es geht oder wenn ich was ausfinden sollte.

Schon mal danke an alle fürs diskutieren! Vielleicht finden wir ja doch noch was :-)

dass man es im Grunde nicht mehr verwenden kann.

Wieso das? Das Problem tritt ja nur für genau einen Request alle 24h auf. Oder hast du ein anderes Problem?

Nach dem Umzug aus der Subdomain und die Hauptdomain jaennert24.de http://jaennert24.de/ stelle ich fest, dass die Seite fST ohne Verzögerung aufgebaut wird. Allerdings habe ich auch das Sicherheitsupdate für 4.8. installiert und ein Update des ODD-Themes.

Für die Subdomain asv-nv.jaennert24.de wurde dann auch das Sicherheitsupdate und Themeupdate eingespielt. Hier beträgt die Startverzögerung rund 10 Sekunden.

Ich beobachte weiter.

Am 20.12.2019 um 09:58 schrieb Yanick Witschi [emailprotected]:

Okay, also meine ersten Erkenntnisse aus ein paar einfachen Debugging-Statements in der index.php: $kernel->handle() braucht im Problemfall (also 1. Aufruf) 12 Sekunden. Wir können also ausschliessen, dass es sich um terminate() handelt. Auf dem Testserver läuft eh FPM, das war also zu erwarten.
Es wäre zu schön, wenn wir jetzt Blackfire hätten, aber nun gut, dann halt weiterhin alle paar x Stunden ein paar Debugging Statements mehr.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/contao/contao/issues/809?email_source=notifications&email_token=AKMU6QU3S5K5H3FXPYTUPCLQZSCLFA5CNFSM4I3Z7TB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHMKSSY#issuecomment-567847243, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMU6QSVVJQFYQSUXILCWNLQZSCLFANCNFSM4I3Z7TBQ.

Weitere Erkenntnisse (teste noch immer mit einer 4.8):

1. Ich hab mal alle relevanten Verzeichnisse in ein git-Repo committet und vorher und nachher verglichen. Keine Veränderung. Also es liegt nicht daran, dass irgendwelche Cache-Dateien neu geschrieben werden, sie sind alle unverändert.
2. File I/O auf dem betroffenen Server scheint normal. Ist jetzt nicht der schnellste (wohl keine SSD's) aber sonst eigentlich i.O.
3. Beim 1. Aufruf wird Kernel::handle() 2x durchlaufen, ab dem 2. Aufruf nicht mehr.
4. Beim 1. Aufruf dauert das Builden des Containers fast 5 Sekunden (beim 2. Durchlauf nicht mehr).

Das sind Tatsachen, ich interpretiere die mal nicht und versuche weitere Fakten zu sammeln.

Weitere Fakten:
Ich bin mal den Erkenntnissen 3) und 4) vom letzten Mal weiter nachgegangen:

3) Also die 2 Aufrufe sind folgende: Einmal / und einmal /home.html und das obwohl ich explizit direkt /home.html requested habe. Das geschieht auch nur beim ersten Mal. Danach hab ich dieses Phänomen nicht mehr. Ich muss also noch immer davon ausgehen, dass vor diesem Server ein Proxy liegt der irgendwas Seltsames macht und aus einem Request deren zwei macht. Das ist sicherlich für die Performance nicht förderlich, ich habe aber auch festgestellt, dass der zweite Request innerhalb dieses einen eigentlichen Requests wieder schnell ist.

4) Ich konnte es zurückführen auf $this->container = include $cache->getPath() innerhalb von Kernel. Also das reine Includen des gecacheten, fertig kompilierten Containers dauert 3 - 5 Sekunden. Der wiederum ist in der aktuellen Version in etliche weitere Files aufgesplittet (könnten wir ab Symfony 4.4 wieder ändern), was zu weiteren Includes führt. Das ist allerdings eigentlich absichtlich so, weil mehrere kleinere PHP-Dateien zu includen schneller ist (oder war) als eine grosse. Wie dem auch sei, egal ob mehrere kleine oder eine grosse Datei, es dürfte so oder so nicht so lange dauern.

Da auf dem betroffenen Server kein OPCode-Cache aktiv ist (und vorangehende Tests auch keine entsprechende Unterschiede gezeigt haben ausser der erwarteten Performance-Verbesserung) gehe ich inzwischen davon aus, dass ausser dem OPCode noch weitere Informationen innerhalb eines FPM-Workers im Memory gespeichert werden. Anders kann ich mir nicht erklären, dass ein Include ab dem 2. Request dann schnell ist.

Ich werde jetzt noch einen isolierten Test machen: Den Container einfach mal ausserhalb von Symfony/Contao includen und schauen, ob das Resultat das gleiche ist. Damit könnten wir dann m.M.n. ziemlich eindeutig ausschliessen, dass das Problem von Symfony oder von Contao stammt.

Ggf. liegt es dann an PHP selbst bzw. der Server-Setup-Kombination oder was ich mir auch noch vorstellen könnte, wären langsame Includes wegen der Instantiierung von allen noch nicht bekannten Klassen (also Autoloading). Wobei auch das macht eigentlich keinen Sinn, die Klassen werden ja eben ohne OPCache bei jedem Request neu gesucht/geparsed...
Weitere Nachforschungsmöglichkeiten ggf. dann auch zusammen mit dem Hoster: Mich würde z.B. das PHP-FPM Slowlog interessieren, auf das ich leider keinen Zugriff habe.
Ausserdem weiss ich, dass in PHP 7.4 weitere FPM-Verbesserungen (vor allem https://github.com/php/php-src/commit/0ed6c3714087b254c49185568df96a31df76b2ce) eingeflossen sind, ggf. hilft also bereits eine Umstellung auf die 7.4.

So, nach einigen Stunden Debugging kann ich nun mit Gewissheit sagen, dass weder PHP, noch Symfony, noch Contao schuld ist.

Im Falle von @xprojects-de (und ich glaube das ist All-Inkl) liegt es definitiv am Filesystem. Ich denke da wird auf ein Cluster Filesystem (NFS, virutelles FS, ...) gesetzt und File I/O ist einfach langsam (evtl. das Netzwerk, überlastete I/O Devices, hoher I/O Wait...whatever) . Nach dem ersten Aufruf sind dann die Files im Filesystem-Cache oder ggf. sogar im Linux Kernel Page Cache (Disk Cache. Page im Sinne von Memory Page, nicht eine HTML-Seite) und somit schnell erreichbar.
Meine ersten File I/O Tests fanden einfach auf einem bereits aufgewärmten Cache statt und es ist mir somit nicht direkt aufgefallen.

Ein normaler Seitenaufruf ohne Seitencache von Contao lädt in der 4.8 ca. 800-900 PHP-Dateien um die ganze Response zu generieren. Hängt natürlich sehr stark von dem ab, was auf der Seite generiert wird (Extensions etc.), aber ich denke das ist ein guter Durchschnittswert.

Hier ist ein kleines Testscript, das ihr als test.php in euer web Verzeichnis hochladen und dann aufrufen könnt:

<?phprequire_once __DIR__.'/../vendor/autoload.php';$start = microtime(true);$finder = \Symfony\Component\Finder\Finder::create() ->in(__DIR__.'/../vendor/contao') ->files() ->name('*.php') ->contains('<?php');$endFinder = microtime(true);$timeNeededToInstantiateFinder = $endFinder - $start;// Trigger iterator before measuring the time$count = count($finder);$timeNeededToFindFiles = microtime(true) - $endFinder;$output = sprintf('I found %d PHP files in your "vendor/contao" directory.', $count) . "\n";$output .= sprintf('To do so, I used the Symfony Finder component which was instantiated within %02.2f seconds.', $timeNeededToInstantiateFinder) . "\n";$output .= sprintf('Searching the files itself took me %02.2f seconds.', $timeNeededToFindFiles) . "\n";

Es durchsucht das vendor/contao Verzeichnis nach .php-Dateien die <?php enthalten. In meinem Fall waren das 837, ich habe es also einfach deswegen als Vergleichswert gewählt. Dass gerade alle contao Bundles auf diesem Testsystem eine ähnliche Zahl ergeben ist purer Zufall. Nehmt einfach irgend ein Verzeichnis, bei dem ihr auf eine Zahl von 800-900 kommt.
Das sind die Resultate bei 3 aufeinanderfolgenden Aufrufen von heute:

1. AufrufI found 837 PHP files in your "vendor/contao" directory.To do so, I used the Symfony Finder component which was instantiated within 0.03 seconds.Searching the files itself took me 8.93 seconds.2. AufrufI found 837 PHP files in your "vendor/contao" directory.To do so, I used the Symfony Finder component which was instantiated within 0.00 seconds.Searching the files itself took me 2.69 seconds.3. AufrufI found 837 PHP files in your "vendor/contao" directory.To do so, I used the Symfony Finder component which was instantiated within 0.00 seconds.Searching the files itself took me 0.12 seconds.

Es dauert also beim 1. Aufruf 8.9 Sekunden um 837 Dateien zu finden und deren Inhalt zu laden und zu analysieren. Genau das passiert auch, wenn eine PHP-Datei inkludiert (explizit per include/require oder implizit als Abhängigkeit (extends, implements etc.) bzw. via Autoload) wird. Der Inhalt der Datei muss ausgelesen und interpertiert werden.
Es ist natürlich nicht ganz 1:1 zu vergleichen, weil im Falle von meinem Testscript wird noch gesucht und kein Code interpretiert, im Falle von PHP ist der exakte Pfad bereits bekannt dafür muss noch interpretiert werden. Das spielt aber alles eine unwesentliche Rolle, was nebenbei auch beweist, dass die Zend Engine PHP-Files rasend schnell interpretiert.

Ich hatte übrigens auch andere Probleme: Manchmal dauerte die SSH-Verbindung über 20 Sekunden oder schlug komplett fehl. Manchmal dauerte auch ein einfaches ls über 10 Sekunden. Ich denke auch das sind alles Symptome des langsamen Filesystemzugriffs.

Man kann bei den 3 Aufrufen auch sehen, dass die Performance linear zunimmt. Das kann ich auch immer wieder nachstellen, wenn ich z.B. eine Stunde warte, dauert es wieder so 1 Sekunde, nach 2 Stunden deren 2 etc.
Auch das ist ein klares Indiz für mich, dass es am Filesystem liegt, denn Caches funktionieren alle gleich. Man hat eine begrenzte Speichermenge und muss dafür sorgen, dass diese nicht überschritten wird. Sprich, die Cache-Einträge werden mit einer TTL ausgezeichnet und laufen irgendwann ab und dann gibt es natürlich etliche Strategien, wenn das Cache-Limit erreicht ist. Wenn er voll ist und neue Einträge hinzugefügt werden, müssen andere Einträge weichen. Entweder die ältesten werden gelöscht oder diejenigen auf die am wenigsten zugegriffen wurde, die grössten etc. pp. Ggf. konkurrenzieren sich also die verschiedenen Hostings auf diesem Server, weil der Cache zu klein ist, auch das wäre eine mögliche Erklärung.

Den genauen Grund dafür zu klären, wäre dann jetzt die Aufgabe des Hosters.
Für uns können wir das Issue m.M.n. schliessen.

Bleibt noch ein Statement zur Frage "Warum braucht es 900 PHP-Dateien um einen Request zu verarbeiten?" bzw. "Warum tritt das Problem bei Contao 3.5 nicht auf, bei Contao 4.8 aber schon?".

Ich hab mir mal die ganzen Files angesehen:

• HTTP Kernel
• JWT Handling für die Preview/Debug-Modus
• CORS Handling (nelmio/cors-bundle)
• Clickjacking (nelmio/security-bundle)
• 2FA (scheb/two-factor-bundle)
• Session-Handling, Session-Abstraktion
• CSRF-Schutz
• Tranlsation
• Monolog
• HTTPCache
• Routing
• Doctrine DBAL Abstraktion
• RememberMe-Handling -> Doctrine ORM -> Annotations
• Alles greift auf Caches zu -> Symfony Cache
• Contao Image Resizing
• Twig (durch den PrettyErrorScreensListener)

Contao macht einfach sehr viel und die ganzen Implementierungen folgen Best Practices von guter Software-Architektur. Nehmen wir mal als Beispiel die Abstraktion der PHP Superglobals in Request und Response. Das alleine sind 30 PHP-Dateien. Denn Request hat einen ParameterBag, FileBag, ServerBag, HeaderBag, dann die ganze Session-Abstraktion mit sauberen Interfaces, also um einige zu nennen:

• Session plus SessionInterface
• NativeSessionStorage plus SessionStorageInterface
• MetadataBag plus SessionBagInterface
• etc.

Also alleine die ganzen Interfaces machen 160 von den 885 aus, die ich in meinem Test habe.
Die Antwort auf die erste Frage lautet also: Weil es diese 900 Files braucht. Weil man Software in Komponenten mit verschiedenen Zuständigkeiten aufteilt. Weil man Interfaces definiert um Implementierungen flexibel und unabhängig zu halten. Es ist also nichts Schlechtes sondern im Gegenteil, ein hervorragendes Indiz.

Die Antwort auf die zweite Frage ist quasi dieselbe: Contao 3.5 war einfach von dem Problem weniger betroffen weil die Software-Architektur nicht mit Contao 4 zu vergleichen ist. Das sind einfach Welten. Zudem kann und macht Contao 4 einfach auch mehr. Contao 3.5 verfügt über kein automatisches CORS-Handling, keine Clickjacking-Protection, kein 2FA uvm.

Es gibt definitiv Aspekte die optimiert werden könnten. Bspw. kriegt der PrettyErrorScreenListener den Twig Service injected. Das sorgt dafür, dass Twig initialisiert werden muss, was wiederum bedeutet, jede Twig-Extension muss geladen werden und das obwohl der Service danach gar nie benutzt wird, weil gar keine Exception auftritt. Das könnte man durch Proxies und Lazy-Loading von Services bzw. der Nutzung von Service Locators optimieren.
Aber wir müssen realistisch bleiben, auch wenn wir jegliche dieser Services optimieren würden, so wären wir sicher immer noch bei 500 Klassen und somit bei 5 - 6 Sekunden statt 8 - 9 Sekunden.
Die Optimierungen würden Tage wenn nicht Wochen beanspruchen und bringen würde es schlussendlich: Nix.

Übrigens: Auf einem Produktionssystem läuft PHP ja immer mit OPCache. Alles andere ist wie bereits erwähnt kein valider Use Case. Sobald ein File im OPCache liegt, findet auch kein Filesystem-Zugriff mehr statt. Also dann geschieht alles in-memory und die Anzahl der Klassen ist dann auch nicht mehr direkt relevant. Sie wird es natürlich, je nach dem wie der OPCache konfiguriert wurde womit wir wieder beim Thema Cache-Konfiguration sind. Es gilt also erneut zu prüfen wie viel das OPCache Memory Limit (opcache.memory_consumption) beträgt, was die maximale Anzahl Files (opcache.max_accelerated_files) ist oder etwa, wie gross ein File maximal sein darf (opcache.max_file_size).
Aber die Default-Einstellungen (128MB, 10000 Files, kein Filesize-Limit) reichen für Contao längstens (!) aus.

Ich beende hiermit meine Recherchen. Falls jemand findet, er oder sie hätte dadurch einiges gelernt oder sich bedanken möchte: https://github.com/sponsors/toflar 😊

Die Antwort auf die zweite Frage ist quasi dieselbe: Contao 3.5 war einfach von dem Problem weniger betroffen weil die Software-Architektur nicht mit Contao 4 zu vergleichen ist.

Nur um das nochmal zu verdeutlichen: das Problem betrifft ja grundsätzlich auch Contao 3, __oder jede andere Web Applikation auf dem selben Server__. Wie stark sich das Problem auswirkt, hängt einfach von der Komplexität der jeweiligen Web Applikation ab.

Danke für die ausführliche und nachvollziehbare Analyse.

Werde es an meinen Hoster weiterleiten

Gruß

Erich

🍃Please consider the environment before printing this mail.

Hallo Yanick,

mittlerweile läuft meine Seite jaennert24.de http://jaennert24.de/ wie erwartet. Mein Provider hat einen neuen Server aufgesetzt und dabei deine Ergebnisse mit berücksichtigt.

Er teilte dazu u.a. folgendes mit:

… die Serverinstallationen etc von Zuhause aus macht, hat er
sich abends hingesetzt und den Server für mich in Ruhe aufgesetzt.
Dabei sind im einige Ungereimtheiten, sowie eine sehr hohe
Empfindlichkeit des Contao Systemes aufgefallen.
Daher muß man an etlichen Stellen sehr genau auf Konfiguration etc
achten.

Das Problem ist aber, dass hierdurch andere Systeme auf solchen
Servern Probleme bekommen können, weil die eine robuste gutmütige
Konfiguration erwarten. (Mal Laienhaft ausgedrückt)

Wenn Du da die anderen Hoster anschaust haben die einen hohen
Supportaufkommen bezüglich Contao und haben daher in Ihren FAQ
eindeutige Hinweise zu abweichende Maßnahmen angegeben um Contao zum
laufen zu bekommen.
Manche Pakete von denen werden auch klar als NICHT für Contao geeignet
ausgewiesen.

Wie Du gesehen hast stehen ja mehreree PHP Versionen zru Verfügung.
Wir mußten feststellen, dass sich Contao unter allen php Versionen
unterschiedlich verhalten hat. Das dürfte so eigentlich gar nicht
passieren. Hier werden die Entwickler von Contao noch sehr viel machen
müssen um Contao bei den Usern wirklich populär und interessant zu
machen.
Auch die Templates sind derzeit in keiner Weise förderlich für einen
User Zugewinn.

Aber gut - wie gesagt der Server ist entsprechend konfiguriert.
Es kann sich in den nächsten noch einige Kleinigkeiten ändern, weil
entsprechende Anpassungen für Wordpress und einige andere Systeme
gemacht werden müssen.

Vielleicht hilft das bei der weiteren Entwicklung von Contao. Meine Seite ist bei Mintdata.net http://mintdata.net/ gehostet.

Gruß

Erich

Am 07.01.2020 um 10:36 schrieb Yanick Witschi [emailprotected]:

So, nach einigen Stunden Debugging kann ich nun mit Gewissheit sagen, dass weder PHP, noch Symfony, noch Contao schuld ist.

Im Falle von @xprojects-de https://github.com/xprojects-de (und ich glaube das ist All-Inkl) liegt es definitiv am Filesystem. Ich denke da wird auf ein Cluster Filesystem (NFS, virutelles FS, ...) gesetzt und File I/O ist einfach langsam (evtl. das Netzwerk, überlastete I/O Devices, hoher I/O Wait...whatever) . Nach dem ersten Aufruf sind dann die Files im Filesystem-Cache oder ggf. sogar im Linux Kernel Page Cache https://en.wikipedia.org/wiki/Page_cache (Disk Cache. Page im Sinne von Memory Page, nicht eine HTML-Seite) und somit schnell erreichbar.
Meine ersten File I/O Tests https://github.com/contao/contao/issues/809#issuecomment-569685985 fanden einfach auf einem bereits aufgewärmten Cache statt und es ist mir somit nicht direkt aufgefallen.

Ein normaler Seitenaufruf ohne Seitencache von Contao lädt in der 4.8 ca. 800-900 PHP-Dateien um die ganze Response zu generieren. Hängt natürlich sehr stark von dem ab, was auf der Seite generiert wird (Extensions etc.), aber ich denke das ist ein guter Durchschnittswert.

Hier ist ein kleines Testscript, das ihr als test.php in euer web Verzeichnis hochladen und dann aufrufen könnt:

require_once __DIR__.'/../vendor/autoload.php';
$start = microtime(true);

$finder = \Symfony\Component\Finder\Finder::create()
->in(__DIR__.'/../vendor/contao')
->files()
->name('*.php')
->contains(' ;

$endFinder = microtime(true);
$timeNeededToInstantiateFinder = $endFinder - $start;

// Trigger iterator before measuring the time
$count = count($finder);
$timeNeededToFindFiles = microtime(true) - $endFinder;

$output = sprintf('I found %d PHP files in your "vendor/contao" directory.', $count) . "\n";
$output .= sprintf('To do so, I used the Symfony Finder component which was instantiated within %02.2f seconds.', $timeNeededToInstantiateFinder) . "\n";
$output .= sprintf('Searching the files itself took me %02.2f seconds.', $timeNeededToFindFiles) . "\n";
Es durchsucht das vendor/contao Verzeichnis nach .php-Dateien die Das sind die Resultate bei 3 aufeinanderfolgenden Aufrufen von heute:

1. Aufruf

I found 837 PHP files in your "vendor/contao" directory.
To do so, I used the Symfony Finder component which was instantiated within 0.03 seconds.
Searching the files itself took me 8.93 seconds.

1. Aufruf

I found 837 PHP files in your "vendor/contao" directory.
To do so, I used the Symfony Finder component which was instantiated within 0.00 seconds.
Searching the files itself took me 2.69 seconds.

1. Aufruf

I found 837 PHP files in your "vendor/contao" directory.
To do so, I used the Symfony Finder component which was instantiated within 0.00 seconds.
Searching the files itself took me 0.12 seconds.
Es dauert also beim 1. Aufruf 8.9 Sekunden um 837 Dateien zu finden und deren Inhalt zu laden und zu interpretieren. Genau das passiert auch, wenn eine PHP-Datei inkludiert (explizit per include/require oder implizit als Abhängigkeit (extends, implements etc.) bzw. via Autoload) wird. Der Inhalt der Datei muss ausgelesen und interpertiert werden.
Es ist natürlich nicht ganz 1:1 zu vergleichen, weil im Falle von meinem Testscript wird noch gesucht und kein Code interpretiert, im Falle von PHP ist der exakte Pfad bereits bekannt dafür muss noch interpretiert werden. Das spielt aber alles eine unwesentliche Rolle, was nebenbei auch beweist, dass die Zend Engine PHP-Files rasend schnell interpretiert.

Ich hatte übrigens auch andere Probleme: Manchmal dauerte die SSH-Verbindung über 20 Sekunden oder schlug komplett fehl. Manchmal dauerte auch ein einfaches ls über 10 Sekunden. Ich denke auch das sind alles Symptome des langsamen Filesystemzugriffs.

Man kann bei den 3 Aufrufen auch sehen, dass die Performance linear zunimmt. Das kann ich auch immer wieder nachstellen, wenn ich z.B. eine Stunde warte, dauert es wieder so 1 Sekunde, nach 2 Stunden deren 2 etc.
Auch das ist ein klares Indiz für mich, dass es am Filesystem liegt, denn Caches funktionieren alle gleich. Man hat eine begrenzte Speichermenge und muss dafür sorgen, dass diese nicht überschritten wird. Sprich, die Cache-Einträge werden mit einer TTL ausgezeichnet und laufen irgendwann ab und dann gibt es natürlich etliche Strategien, wenn das Cache-Limit erreicht ist. Wenn er voll ist und neue Einträge hinzugefügt werden, müssen andere Einträge weichen. Entweder die ältesten werden gelöscht oder diejenigen auf die am wenigsten zugegriffen wurde, die grössten etc. pp. Ggf. konkurrenzieren sich also die verschiedenen Hostings auf diesem Server, weil der Cache zu klein ist, auch das wäre eine mögliche Erklärung.

Den genauen Grund dafür zu klären, wäre dann jetzt die Aufgabe des Hosters.
Für uns können wir das Issue m.M.n. schliessen.

Bleibt noch ein Statement zur Frage "Warum braucht es 900 PHP-Dateien um einen Request zu verarbeiten?" bzw. "Warum tritt das Problem bei Contao 3.5 nicht auf, bei Contao 4.8 aber schon?".

Ich hab mir mal die ganzen Files angesehen:

HTTP Kernel
JWT Handling für die Preview/Debug-Modus
CORS Handling (nelmio/cors-bundle)
Clickjacking (nelmio/security-bundle)
2FA (scheb/two-factor-bundle)
Session-Handling, Session-Abstraktion
CSRF-Schutz
Tranlsation
Monolog
HTTPCache
Routing
Doctrine DBAL Abstraktion
RememberMe-Handling -> Doctrine ORM -> Annotations
Alles greift auf Caches zu -> Symfony Cache
Contao Image Resizing
Twig (durch den PrettyErrorScreensListener)
Contao macht einfach sehr viel und die ganzen Implementierungen folgen Best Practices von guter Software-Architektur. Nehmen wir mal als Beispiel die Abstraktion der PHP Superglobals in Request und Response. Das alleine sind 30 PHP-Dateien. Denn Request hat einen ParameterBag, FileBag, ServerBag, HeaderBag, dann die ganze Session-Abstraktion mit sauberen Interfaces, also um einige zu nennen:

Session plus SessionInterface
NativeSessionStorage plus SessionStorageInterface
MetadataBag plus SessionBagInterface
etc.
Also alleine die ganzen Interfaces machen 160 von den 885 aus, die ich in meinem Test habe.
Die Antwort auf die erste Frage lautet also: Weil es diese 900 Files braucht. Weil man Software in Komponenten mit verschiedenen Zuständigkeiten aufteilt. Weil man Interfaces definiert um Implementierungen flexibel und unabhängig zu halten. Es ist also nichts Schlechtes sondern im Gegenteil, ein hervorragendes Indiz.

Die Antwort auf die zweite Frage ist quasi dieselbe: Contao 3.5 war einfach von dem Problem weniger betroffen weil die Software-Architektur nicht mit Contao 4 zu vergleichen ist. Das sind einfach Welten. Zudem kann und macht Contao 4 einfach auch mehr. Contao 3.5 verfügt über kein automatisches CORS-Handling, keine Clickjacking-Protection, kein 2FA uvm.

Es gibt definitiv Aspekte die optimiert werden könnten. Bspw. kriegt der PrettyErrorScreenListener den Twig Service injected. Das sorgt dafür, dass Twig initialisiert werden muss, was wiederum bedeutet, jede Twig-Extension muss geladen werden und das obwohl der Service danach gar nie benutzt wird, weil gar keine Exception auftritt. Das könnte man durch Proxies und Lazy-Loading von Services bzw. der Nutzung von Service Locators optimieren.
Aber wir müssen realistisch bleiben, auch wenn wir jegliche dieser Services optimieren würden, so wären wir sicher immer noch bei 500 Klassen und somit bei 5 - 6 Sekunden statt 8 - 9 Sekunden.
Die Optimierungen würden Tage wenn nicht Wochen beanspruchen und bringen würde es schlussendlich: Nix.

Übrigens: Auf einem Produktionssystem läuft PHP ja immer mit OPCache. Alles andere ist wie bereits erwähnt kein valider Use Case. Sobald ein File im OPCache liegt, findet auch kein Filesystem-Zugriff mehr statt. Also dann geschieht alles in-memory und die Anzahl der Klassen ist dann auch nicht mehr direkt relevant. Sie wird es natürlich, je nach dem wie der OPCache konfiguriert wurde womit wir wieder beim Thema Cache-Konfiguration sind. Es gilt also erneut zu prüfen wie viel das OPCache Memory Limit (opcache.memory_consumption) beträgt, was die maximale Anzahl Files (opcache.max_accelerated_files) ist oder etwa, wie gross ein File maximal sein darf (opcache.max_file_size).
Aber die Default-Einstellungen (128MB, 10000 Files, kein Filesize-Limit) reichen für Contao längstens (!) aus.

Ich beende hiermit meine Recherchen. Falls jemand findet, er oder sie hätte dadurch einiges gelernt oder sich bedanken möchte: https://github.com/sponsors/toflar https://github.com/sponsors/toflar 😊

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/contao/contao/issues/809?email_source=notifications&email_token=AKMU6QVMF2RD3SM25IQ5453Q4REK3A5CNFSM4I3Z7TB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIIIXOY#issuecomment-571509691, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMU6QXNDDBXZODGT5OPSPTQ4REK3ANCNFSM4I3Z7TBQ.

Dabei sind im einige Ungereimtheiten, sowie eine sehr hohe
Empfindlichkeit des Contao Systemes aufgefallen.
Daher muß man an etlichen Stellen sehr genau auf Konfiguration etc
achten.

Das Problem ist aber, dass hierdurch andere Systeme auf solchen
Servern Probleme bekommen können, weil die eine robuste gutmütige
Konfiguration erwarten. (Mal Laienhaft ausgedrückt)

:shrug: das ist doch Käse

Okay, das kann ich nicht beurteilen und habe die Information weitergegeben. Tatsche ist, dass der neue Server richtig schnell ist.

Am 25.05.2020 um 16:26 schrieb M. Vondano [emailprotected]:

Dabei sind im einige Ungereimtheiten, sowie eine sehr hohe
Empfindlichkeit des Contao Systemes aufgefallen.
Daher muß man an etlichen Stellen sehr genau auf Konfiguration etc
achten.

Das Problem ist aber, dass hierdurch andere Systeme auf solchen
Servern Probleme bekommen können, weil die eine robuste gutmütige
Konfiguration erwarten. (Mal Laienhaft ausgedrückt)

🤷 das ist doch Käse

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/contao/contao/issues/809#issuecomment-633597375, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMU6QXQ6AG4234TJENVSPLRTJ5YHANCNFSM4I3Z7TBQ.

Ja, sollte kein Angriff gegen dich sein. :slightly_smiling_face:

Diese Aussagen sind halt nur wenig hilfreich und es klingt so als wäre es ein Problem eine Contao/Symfony Applikation zu hosten.

Daher muß man an etlichen Stellen sehr genau auf Konfiguration etc achten.

Ja, das hat Konfiguration so an sich. Wenn ein Parameter irrelevant wäre, müsste man ihn auch nicht konfigurierbar machen? Also man sollte schon generell auf Konfiguration achten...
Ich verstehe nicht, was diese Aussage bezwecken soll.

Das Problem ist aber, dass hierdurch andere Systeme auf solchen Servern Probleme bekommen können, weil die eine robuste gutmütige Konfiguration erwarten. (Mal Laienhaft ausgedrückt)

Was auch immer eine "robuste gutmütige Konfiguration" sein soll. Contao stellt keine besonderen Anforderungen an den Server. Wirklich nicht.
Und wenn ein System eines Kunden potenziell ein anderes eines anderen Kunden beeinflussen kann, würde ich das Server-Setup stark in Frage stellen.

Wie Du gesehen hast stehen ja mehreree PHP Versionen zru Verfügung. Wir mußten feststellen, dass sich Contao unter allen php Versionen unterschiedlich verhalten hat. Das dürfte so eigentlich gar nicht passieren.

Was heisst denn "unterschiedlich verhalten"? Das ist ja noch fast besser als "robuste gutmütige Konfiguration"...
Natürlich gibt es Dinge die anders sind, neuere PHP-Versionen können ja auch mehr. Aber wie gesagt, mit so einer schwammigen Aussage können wir herzlich wenig anfangen.

Also wenn du mich fragst, ist das alles bisschen ungenau und es klingt danach, als würde man einfach die Schuld uns zuschieben wollen. Das ist imho ein höchst unprofessionelles Verhalten.
Wir sind Menschen und mit uns kann man reden. Anstatt irgendwas zu behaupten, könnte man einfach mit uns Kontakt aufnehmen oder einfach hier ein Ticket anlegen. Es ist ja ein Open Source-Projekt und lebt von den Beiträgen der Community. Ggf. lässt sich was optimieren, so dass es zur Zufriedenheit aller Parteien geändert werden kann.

Aber bitte mit konkreten technischen Vorschlägen und nicht mit "robuster gutmütiger Konfiguration".

Für mich war wichtig, dass mit den ausführlichen Informationen von Yanick ein optimaler Server für Contao aufgesetzt werden konnte. Mit technischen Details kann ich nicht dienen.

Am 25.05.2020 um 16:54 schrieb Yanick Witschi [emailprotected]:

Und das gilt für alle in diesem Thread: Ich weiss, jeder verteidigt sein geliebtes System und sein eigenes Können gerne und gibt ungern Fehler zu, aber lasst uns bitte nicht einen Schuldigen finden oder jemanden als unerfahren oder unqualifiziert hinstellen.
Contao ist OSS und OSS ist deshalb so gut, weil so viele Leute ihr Wissen gemeinsam in ein Projekt stecken und bereit dazu sind, voneinander zu lernen.
Choose your words wisely.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/contao/contao/issues/809#issuecomment-633609205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMU6QWXM2VVF25ZCDXO4Y3RTKBCZANCNFSM4I3Z7TBQ.

Frag deinen Hoster doch mal, was genau er bei dem neuen Server anders konfiguriert hat. Ich hab aktuell zwei sehr ähnliche Installationen beim gleichen hoster, beide male "kleine" Pakete bei Ionos, aber die Antwortzeit beim ersten Aufurf ist deutlich unterschiedlich.

@woluka Du könntest die phpinfo() von beiden Installationen abrufen (Contao Manager -> Tools -> PHP Informationen) und diese hier posten oder selbst vergleichen.

Frag deinen Hoster doch mal, was genau er bei dem neuen Server anders konfiguriert hat. Ich hab aktuell zwei sehr ähnliche Installationen beim gleichen hoster, beide male "kleine" Pakete bei Ionos, aber die Antwortzeit beim ersten Aufurf ist deutlich unterschiedlich.

@woluka Du könntest die phpinfo() von beiden Installationen abrufen (Contao Manager -> Tools -> PHP Informationen) und diese hier posten oder selbst vergleichen.

phpinfos.zip

Für mich sehen die identisch aus, ist wie gesagt beides Ionos, gleiche PHP-Version. Die langsamere Seite wird allerdings über eine Subdomain aufgerufen, ich hatte schon bei anderen Seiten den Eindruck, dass das einen Einfluss hat. Während der Entwicklung unter develop.domain.tld hatte ich beim ersten Aufruf ein Delay, nach dem Goning live unter domain.tld war es weg. Wirklich gemessen hab ich es nicht, sorry. Beim nächsten Projekt mach ich das.

Hier die phpinfos:

Am 26.05.2020 um 16:56 schrieb woluka [emailprotected]:

Frag deinen Hoster doch mal, was genau er bei dem neuen Server anders konfiguriert hat. Ich hab aktuell zwei sehr ähnliche Installationen beim gleichen hoster, beide male "kleine" Pakete bei Ionos, aber die Antwortzeit beim ersten Aufurf ist deutlich unterschiedlich.

@woluka https://github.com/woluka Du könntest die phpinfo() von beiden Installationen abrufen (Contao Manager -> Tools -> PHP Informationen) und diese hier posten oder selbst vergleichen.

phpinfos.zip https://github.com/contao/contao/files/4683027/phpinfos.zip
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/contao/contao/issues/809#issuecomment-634077545, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKMU6QSFU23NA36VOXX3JRTRTPKAXANCNFSM4I3Z7TBQ.

@jaennert du darfst auf diese Threads nicht per E-Mail antworten. Deine Attachments gehen dadurch verloren.

Aber generell vermute ich, dass es nichts mit php.ini Einstellungen zu tun hat? @jaennert kannst du deinen Hoster nicht einfach fragen, was er denn genau in der Serverumgebung für Contao anders eingestellt hat? Der muss das ja wissen.

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen