Skriptcache läuft unter X6 voll

[EBL]

Hi,
in unseren X6 Installationen wächst seit dem Update der Skriptcache extrem an. Woran könnte das liegen und wie können wir das eindämmen?

[EBL]

Dasselbe betrifft wohl auch den CSS Cache, siehe Anhang.

[Tim]

Ich kenne Contaos-Datei-Caching Logik nicht im Detail. Wieviele Webseiten werden in dieser Installationen gehostet?

[EBL]

Es tritt bisher bei allen unseren X6 Installationen auf, manche Multi- manche Single Domain.

[Tim]

Grundsätzlich ists ja richtig, dass die Dateien geschrieben werden. Das ist ja quasi Contaos zusammengepresste Files - die Methode existiert in dieser Form bereits seit Eclipse9. -> Quasi Contaos |static Methode.
Alternantive wäre http2 nutzen - wenn der Hoster es zulässt (all-inkl erlaubt das). In diesem Fall liefert das System die Dateien nicht "kombiniert" aus, sondern einzeln.

Meines Erachtens ist der Seitencache dafür gedacht. Ist der nicht richtig aktiv, wird eine neue Seite ausgeliefert, die wiederum Files neu generiert. Das füllt Stück für Stück (Seite für Seite) den Ordner. Dateinamen-Logik von Contao ist hier eine Art unique Anhängsel je Seite (die genaue Logik kenne ich nicht).

[EBL]

Ja, wenn eine Seite aus dem Seitencache kommt, werden die Dateien anscheinend nicht generiert. Das kommt mir aber schon exzessiv vor, wir haben an den Caching Einstellungen ja nichts verändert & seit dem Sprung auf X6 & Contao 5 jetzt aber tw. mehrere 100.000 Dateien in den Assets Dazu kommt ja, dass vieles das Caching komplett verhindern kann (Session Cookie, {{date::Y}} Insert Tag, etc.).

[Tim]

Das ist theme-seitig quasi seit 10 Jahren unverändert. Ich weiss jetzt nicht, ob Contao 5 hier noch etwas anders macht, als 4. Aber es war schon immer so, dass die Combiner-Files oder auch TL_CSS/TL_JAVASCRIPT mit static Flagge etc., zu einem File abgelegt werden mit einem eindeutigen Anhängsel je Seite. Das ist so auch technisch korrekt, weil der Quellinhalt natürlich von Seite zu Seite (und Parametern etc) variieren kann.

Ja, das schon ne Menge Holz. Aber vieles ist auch schlichtweg der Masse an Seiten geschuldet. Man kann sich ja nen Cronjob legen, der den Ordner einmal in der Woche leert z.B. je nach Seitencache Zeit, oder so.

Ja, wenn eine Seite aus dem Seitencache kommt, werden die Dateien anscheinend nicht generiert.

Jup. Dafür ist er gedacht.

[EBL]

Was allerdings auch auffällt, ist dass die files unendlich oft pro Seite abgelegt werden, also im Prinzip bei jedem refresh. Wenn das Ganze auf die Anzahl der Seiten beschränkt wäre, könnte man das ja noch verkraften.

*Edit: Jetzt entstehen doch auch Einträge bei gecacheten Seiten (Contao cache header: fresh, geschützte Umgebung, keine externen Aufrufe)

[Tim]

Was allerdings auch auffällt, ist dass die files unendlich oft pro Seite abgelegt werden, also im Prinzip bei jedem refresh. Wenn das Ganze auf die Anzahl der Seiten beschränkt wäre, könnte man das ja noch verkraften.

*Edit: Jetzt entstehen doch auch Einträge bei gecacheten Seiten (Contao cache header: fresh, geschützte Umgebung, keine externen Aufrufe)

Das kann ich nicht bestätigen. Die Daten aus dem Script-Cache (/assets Ordner) verbleiben identisch, unabhängig des Seiten-Refresh.

Getest hier (kein Seitencache aktiv)
https://dev53.premium-contao-themes....ages/headlines

<link rel="stylesheet" href="/assets/css/styles.css,customcatalog.css,themify-icons.css,font-awesome.min....-a0b7cdfa.css">
<script defer="" src="/assets/js/doubletaptogo.js,typed.js,accessibility_widget.js, jquery-ui.min....-41b45d1d.js"></script>

Das ganze baut auf Contas interne Systeme auf. Ich hab mal den Crawler durch die Dev rödeln lassen. Da kommen ca. 200 Dateien bei raus. Was ca. der Anzahl an Seiten entspricht in dieser Installation entspricht. Passt. Wenn Du eine bessere Methode siehst, die ebenfalls contao-konform ist, gern her damit.

Du kannst die Combiner - Logik der Kern-Dateien auch frei ändern. Seit jeher ist die Logik direkt in der fe_page verbaut. Basiert auf dem Assets Management via TL_CSS

[EBL]

Hm, aber dort sieht es auch danach aus, als würden hier jedes Mal neue assets generiert werden.. CSS bleibt konsistent, aber das Skript File ändert sich.

[Tim]

Seit dem Aufruf gestern bekomme ich das File mit dem Anhängsel "-a0b7...".

Du musst im Hinterkopf behalten, dass jede Form von Quelltext-Änderung (z.B. ein neuer Text in der Seite) unweigerlich auch Contao veranlassen wird eine neue Datei zu erstellen. Ja, das füllt sich...

Ich würde einfach in regelmäßigen Abständen den Ordner leeren, wenn es wirklich zu Speicherproblemen kommen sollte. (vielleicht macht das Contao ohnehin automatisch in einen seiner Cronjobs) oder binde auch unter http1 die Files strikt statisch im fe_page Template ein, wie es quasi unter https2 der Fall ist.

[EBL]

Ja bei den Styles tritt der Fehler hier nicht auf, aber schau mal auf der Seite nach dem doubletaptogo... Skript asset, das wird auch auf https://dev53.premium-contao-themes....ages/headlines bei jedem Reload neu generiert. Das sollte m.E. schon gefixt werden. Wir hatten schon Probleme wegen sehr großer Filesize durch dieses Thema und es betrifft ja dann auch nicht nur uns.

oder binde auch unter http1 die Files strikt statisch im fe_page Template ein, wie es quasi unter https2 der Fall ist.

Ist notiert

[Tim]

Wir hatten schon Probleme wegen sehr großer Filesize durch dieses Thema und es betrifft ja dann auch nicht nur uns.

Ah pass auf. Ich glaube ich weiss, warum das plötzlich einen Unterschied macht. Die Datei "seo_scripts" wird dynamisch generiert aus Script-Inhalten in der Seite (was sonst quasi inline Scripte wären mitten im Body). Das veranlasst den Combiner ein neues File zu erstellen.

...
Tatsächlich. Das File darf nicht in den Combiner. Das muss quasi wie die customize.css individuell geladen werden. Verrückt.

Kommt ins nächste Update!

Schau bitte noch einmal: https://dev53.premium-contao-themes....ages/headlines

[EBL]

Schau bitte noch einmal: https://dev53.premium-contao-themes....ages/headlines

Sieht gut aus, vielen Dank!