Performanceverlust bei sehr vielen Nachrichtenteasern

[tschero]

Hallo Leute,

ich habe eine Website auf welcher drei Seiten bestehen, die sehr viele Nachrichtenteaser enthalten - bis zu 220 Stück.
Das hat vorerst seinen Grund.

Die Ladezeit einer einzelnen Seite bewegt sich jedoch im Bereich 20 Sekunden, was natürlich sehr unschön ist.

Gibt es in Contao irgendeine Beschränkung, die den Einsatz sehr vieler Nachrichten auf einer Seite nicht empfehlen oder gar erlauben?
Bisher habe ich nichts dazu gefunden und möchte die Performance verbessern.

Hier gibt´s einige Info´s zum Debugmodus auf der betroffenen Seite:
https://community.contao.org/de/show...l=1#post536236

Ich verwende ein externes Theme mit Contao 4.9.9

Über Hinweise würde ich mich freuen.

Gruß
tschero

[tschero]

Nachdem die Seiten beim Nutzer einmal aufgerufen wurden, greifen die ganzen Cacheeinstellungen scheinbar.
Hier ist dann die Ladezeit unter einer Sekunde.

Das Problem liegt weiterhin an der Ladezeit beim ersten Aufruf.


- op_cache ist aktiviert
- realpath cache ist auch aktiviert
- verwendeter Font Awesome wird lokal geladen
- JQuery wird lokal geladen
- Es werden keine externen Schriftarten eingebunden
- Im Startpunkt der Seite ist der Cache wie folgt eingestellt:
--Cachezeit Private-Cache: 30 Tage
-- Cachezeit Shared Cache: 3 Monate
-- Immer aus dem Shared Cache laden ist ausgewählt

So langsam gehe mir auch die Ideen aus.

Für Tipp´s bin ich sehr dankbar.

Gruß
tschero

[Spooky]

Es wird schwer sein hier irgendeine pauschale Aussage zu machen. Du musst einfach eine Performance Analyse machen oder in Auftrag geben.

Je nach dem wie du diese 220 Nachrichten darstellen lässt, was sich in den Templates befindet etc. könnte es aber schon einige Zeit dauern, je nach Hosting.

Aber für genau sowas ist ja Caching da. Den shared Cache kannst du gleich auf 1 Jahr stellen.

[tab]

Hast du vielleicht irgendwelche Teile der Seite, die nicht cachebar sind? Ich würde einfach mal mit den Browsertools nachprüfen, ob die Seiten überhaupt jemals aus dem Public Cache (Contao-Cache auf dem Server) geladen werden, denn wenn es erst schneller wird, wenn der Nutzer die Seite aufruft und nicht auch schon wenn du sie aufrufst, dann deutet das m.E. eher darauf hin, dass die Seiten danach aus dem Private Cache (Browsercache) kommen.

[Spooky]

Poste mal die betroffene URL.

[tschero]

Die Seite ist noch im Wartungsmodus.

Ich schicke den Zugang per PN.

[tschero]

Moin @tab

Hast du vielleicht irgendwelche Teile der Seite, die nicht cachebar sind?...

Ich weiß es nicht. Jedenfalls nicht wissentlich eingestellt und ich finde nirgendwo Dinge die nicht gecached werden sollen.

Ich würde einfach mal mit den Browsertools nachprüfen, ob die Seiten überhaupt jemals aus dem Public Cache (Contao-Cache auf dem Server) geladen werden, denn wenn es erst schneller wird, wenn der Nutzer die Seite aufruft und nicht auch schon wenn du sie aufrufst, dann deutet das m.E. eher darauf hin, dass die Seiten danach aus dem Private Cache (Browsercache) kommen.

Ja, das kommt mir auch so vor.
Mit den Browsertool (FF) habe ich folgende Tests durchgeführt:

ferienhaeuser_erster_Aufruf.jpg
ferienhaeuser_zweiter_Aufruf.jpg
ferienhaeuser_dritter_Aufruf.jpg

Was ich seltsam finde ist, dass überall bei Antworten aus dem Cahce eine 0 (Null) steht.
Kann das am Wartungsmodus liegen?

Gruß
tschero

[Spooky]

Ob etwas aus dem shared Cache kommt oder nicht siehst du in den Response Header, sofern du die neueste Contao Version installiert hast.

[tschero]

Installiert ist 4.9.9 .

[Spooky]

Contao meldet auf jeden Fall folgendes:

Contao-Private-Response-Reason: session-cookie

Das ist jedoch seltsam, da du ja die Funktion Immer aus dem Shared-Cache laden aktiviert hast.

Aber da du die Seite noch im Wartungsmodus hast, ist es schwer zu sagen, ob es vielleicht damit etwas zu tun hat. Du solltest die Seite stattdessen lieber per Server Konfiguration absichern (.htaccess + .htpasswd) und dann nochmal genauere Tests mit dem Cache machen, in einem Privaten Browser Fenster.

[tschero]

Inhalt .htaccess:

##
#  Protect backend
##
SetEnvIf Request_URI ^/(contao($|/)|contao-manager\.phar\.php($|/)) require_auth=true
AuthUserFile /var/www/clients/client0/web2/web/xxxxxxxxxxx/web/.htpasswd
AuthGroupFile /dev/null
AuthName "Contao Backend Authentification"
AuthType Basic
require valid-user
Order deny,allow
Deny from all
Allow from env=!require_auth
Satisfy any

Inhalt .tpasswd:

xyz:$apr1$lfipr91m$WFhqR.Zu7LbxbUd.iN1Ycdtm0verändert

Server liefert Fehler 500.

Beide Dateien liegen in web.

Jemand eine Idee warum das so nicht funktioniert?

[Spooky]

Damit würdest du nur das Backend absichern. Ich dachte du willst generell nicht, dass die Seite öffentlich verfügbar ist?

[tschero]

Das ist richtig,

was müsste ich denn dann verändern und warum liefert der Server Fehler 500?

[Spooky]

Dann würde ich einfach folgendes schreiben:

AuthUserFile /path/to/.htpasswd
AuthName "Authorisation required"
AuthType Basic
Order Deny,Allow
Deny from all
Satisfy any
Require valid-user

[tschero]

Oh, das funktioniert.
Herzlichen Dank.

[Spooky]

Ok, das mit dem Passwort Schutz hilft aber auch nicht, weil jetzt funktioniert der Cache genau deswegen nicht

Contao-Private-Response-Reason: authorization

[Spooky]

Das Problem könnten die News Templates des Eclipse Themes sein. Dort befindet sich 3x if ($this->hasText) und einmal $this->text ? … : … im vewendeten News Template. Dadurch werden 220 x 4 = 880 Datenbankabfragen alleine nur deswegen ausgeführt. Ob die Datenbankabfragen das Problem sind, könnte man mit dem Debug-Modus rausfinden, aber auf deinem Hosting funktioniert dieser nicht auf genau den problematischen Seiten. Evt. wegen Script Timeout oder RAM overflow?

[Spooky]

Ich habe nun ein neues Template namens news_portfoliolist_v7_optimised.html5 angelegt, wo ich alle Abfragen auf ->hasText und ->text entfernt habe. Damit kannst du die TTFB von 20000 bis 31000ms auf ~1200ms reduzieren, also 20 mal schneller . Hinweis: mit diesem Template wird nun aber immer auf die Detailseite verlinkt, auch wenn es keinen Detailinhalt gäbe.

[Spooky]

Du könntest noch folgendes Feedback an den Theme Hersteller schreiben:

1. In einem Newslisten Template sollte $this->hasText nur einmal verwendet werden, damit nicht mehrmals die selbe Datenbankabfrage gemacht wird. Falls es mehrmals benötigt wird, sollte es in einer Variable zwischengespeichert werden ($hasText = $this->hasText();).
2. In einem Newslisten Template sollte $this->text gar nicht verwendet werden - es sei denn man will den Detailinhalt einer Nachricht auch tatsächlich ausgeben. Für die bloße Abfrage, ob es Detailinhalt gibt, sollte $this->hasText verwendet werden (und dann gilt wieder Punkt 1).

Aber: auch wenn der Theme-Hersteller das behebt ist es immer noch besser, die Nachrichtenliste den eigenen Bedürfnissen anzupassen, um die beste TTFB zu erlangen. Wenn du also eine Nachrichtenliste hast, wo du weißt, dass sowieso immer auf die Detailseite verlinkt werden soll, dann kannst du eben das entsprechende Newslisten Template so anpassen, dass kein $this->hasText benutzt wird.


// Achja: vorausgesetzt, das Template war nicht von euch so verändert worden

[tschero]

Ok, das mit dem Passwort Schutz hilft aber auch nicht, weil jetzt funktioniert der Cache genau deswegen nicht

Contao-Private-Response-Reason: authorization

Was habe ich denn sonst noch für Testmöglichkeiten wenn der Wartungsmodus und .htaccess mit .htpasswd wegfällt?

[tab]

Oh, mir fällt da gerade was ein. Das mit dem "Immer aus dem Shared Cache laden" ist auch nicht das Allheilmittel. Ich habe das auch mal gehabt. Denn solange du durch htaccess und htpasswd die Seite schützt, wird eine Seite, die noch nicht im Shared Cache ist oder die zwar im Shared Cache liegt, aber deren dortiger Eintrag durch Änderung der Seite invalide wird, gar nicht mehr in den Shared Cache aufgenommen. Das ist so gewollt und durchaus aus guten Gründen so, aber halt in deiner Situation nicht so besonders geschickt.

Die Shared Cache Version einer Seite wird nach einer Seitenänderung als invalide markiert. Ohne den Schutz durch htaccess und htpasswd würde sie beim nächsten Aufruf der Seite automatisch neu berechnet und das Ergebnis im Shared Cache abgelegt. Weitere Aufrufe kämen dann aus dem Shared Cache, bis die für diesen eingestellte Lebensdauer erreicht ist. Mit dem Schutz wird die neu berechnete Seite bei nachfolgenden Aufrufen nicht im Shared Cache abgelegt und folglich bei jedem Aufruf neu berechnet. Außer natürlich, wenn der Browser sie aus dem Private Cache, also dem Browsercache nehmen kann.

Immerhin bleibt dir die Hoffnung, dass sich das Problem weitgehend in Luft auflöst, wenn erst dein Passwortschutz irgendwann weg ist, während bei meiner Seite der Passwortschutz dauerhaft bestehen bleiben soll. Trotzdem gilt es natürlich, die Neuberechnung der Seiten soweit als möglich zu beschleunigen, ansonsten wird es halt immer mal wieder einen Besucher geben, der eben sehr, sehr lang warten muss nach seinem Seitenaufruf.

[Tim G]

Du könntest noch folgendes Feedback an den Theme Hersteller schreiben:

1. In einem Newslisten Template sollte $this->hasText nur einmal verwendet werden, damit nicht mehrmals die selbe Datenbankabfrage gemacht wird. Falls es mehrmals benötigt wird, sollte es in einer Variable zwischengespeichert werden ($hasText = $this->hasText();).
2. In einem Newslisten Template sollte $this->text gar nicht verwendet werden - es sei denn man will den Detailinhalt einer Nachricht auch tatsächlich ausgeben. Für die bloße Abfrage, ob es Detailinhalt gibt, sollte $this->hasText verwendet werden (und dann gilt wieder Punkt 1).

Aber: auch wenn der Theme-Hersteller das behebt ist es immer noch besser, die Nachrichtenliste den eigenen Bedürfnissen anzupassen, um die beste TTFB zu erlangen. Wenn du also eine Nachrichtenliste hast, wo du weißt, dass sowieso immer auf die Detailseite verlinkt werden soll, dann kannst du eben das entsprechende Newslisten Template so anpassen, dass kein $this->hasText benutzt wird.


// Achja: vorausgesetzt, das Template war nicht von euch so verändert worden

zu 1: Das wäre innerhalb des Template-Objects bzw. Global in Contao nach einmaligen Aufruf besser zwischengespeichert. Ohne in den Code zu schauen, weiss keiner, dass man die Variable nur einmal nutzen sollte. Es ist ohnehin irreführend hier eine Template-Variable zu nutzen und diese auch doppelt zu deklarieren. Einmal boolean, einmal als function.

boolean: https://github.com/contao/news-bundl...eNews.php#L105
function: https://github.com/contao/news-bundl...eNews.php#L144

[Spooky]

zu 1: Das wäre innerhalb des Template-Objects bzw. Global in Contao nach einmaligen Aufruf besser zwischengespeichert. Ohne in den Code zu schauen, weiss keiner, dass man die Variable nur einmal nutzen sollte. Es ist ohnehin irreführend hier eine Template-Variable zu nutzen und diese auch doppelt zu deklarieren. Einmal boolean, einmal als function.

boolean: https://github.com/contao/news-bundl...eNews.php#L105
function: https://github.com/contao/news-bundl...eNews.php#L144

Das wurde aus Performancegründen so geändert. Vorher wurde diese Abfrage immer gemacht. Nach der Implementation als Closure passiert diese Abfrage nur mehr, wenn es tatsächlich gebraucht wird.

Eine Zwischenspeicherung des Results von hasText() und text() pro Template bzw. pro News könntest du ja als PR beisteuern.

[Tim G]

Es gibt keine hasText() Methode. Das wäre zumindest klarer kommuniziert im Template. Nur eine $this->hasText Variable. Das sich dahinter eine Methode versteckt, die ggf. n-fach neu aufgerufen wird und sich auch nicht zwischenspeichert ist aus dem reinen Template nicht ersichtlich.
Bei einer normalen Template-Variablen erwartet man eigentlich keine Methode und einen bereits beschriebenen Wert.

Wie auch Models sich zwischen-speichern, sollte das CMS sich hier ebenfalls zwischenspeichern. Hier reicht die einmalige Wertspeicherung nach ersten Aufruf der Methode und danach die reine Rückgabe des Wertes.

Gleiches gilt für die $this->text Variable.

[Spooky]

Es gibt keine hasText() Methode. Das wäre zumindest klarer kommuniziert im Template. Nur eine $this->hasText Variable. Das sich dahinter eine Methode versteckt, die ggf. n-fach neu aufgerufen wird und sich auch nicht zwischenspeichert ist aus dem reinen Template nicht ersichtlich.

In Contao Templates hast du generell keine Möglichkeit über die IDE zu wissen, was sich genau in einer Variable befindet. Das findest du nur über $this->dumpTemplateVars(); raus.

Wie auch Models sich zwischen speichern, sollte das CMS sich hier ebenfalls zwischen speichern. Hier reicht die einmalige Wertspeicherung nach ersten Aufruf der Methode und danach die reine Rückgabe des Wertes.

Ja wie gesagt, das kannst du ja als PR beisteuern. Der Core an sich braucht es zwar nicht, da das nur einmal benutzt wird. Aber vor allem bei der hasText() Funktion ist es imho feasable, dass man das in Custom News Templates öfter abfragen möchte.

[Tim G]

das news_full template produziert an dieser Stelle schon einen unnötigen Aufruf zu viel. Ich würde es im Core / news_bundle empfehlen mit einer realen Wertspeicherung. Damit kann es nicht zu Engpässen kommen und es tut nicht weh, wenn man mehrfach auf hasText abfrage, wo man allein durch die Benamung vorab bereits einen gesetzten Wert erwartet. Wie bei hasSubHeadline, hasTeaser usw.

ModuleNews.php, Zeile 126

            $objTemplate->text = function () use ($id)
            {
                if( !$this->_text )
                {
                    $strText = '';
                    $objElement = \ContentModel::findPublishedByPidAndTable($id, 'tl_news');

                    if ($objElement !== null)
                    {
                        while ($objElement->next())
                        {
                            $strText .= $this->getContentElement($objElement->current());
                        }
                    }
                    
                    $this->_text = $strText;

                    // content is not empty, no need to count again
                    if( !empty($strText) )
                    {
                        $this->_hasText = true;
                    }
                }

                return $this->_text;
            };

            $objTemplate->hasText = function () use ($objArticle)
            {
                if( !$this->_hasText )
                {
                    $this->_hasText = \ContentModel::countPublishedByPidAndTable($objArticle->id, 'tl_news') > 0;
                }
                return $this->_hasText;
            };
        } 

[Spooky]

das news_full template produziert an dieser Stelle schon einen unnötigen Aufruf zu viel.

Was meinst du damit? hasText und text wird im default news_full Template jeweils nur einmal benutzt.

Ich würde es im Core / news_bundle empfehlen mit einer realen Wertspeicherung. Damit kann es nicht zu Engpässen kommen.

Ja wie gesagt, mach einen Vorschlag dafür als PR für contao/contao.