Performance Contenido 4.9

[chnussbaumer]

Hallo zusammen,

Ich arbeite zur Zeit an einem Projekt mit der Contenido-Version 4.9.7.
Dabei ist mir aufgefallen das die Seite plötzlich ziemlich langsam ist. Die Time2FirstByte ist bei 6-10 sekunden.
Ich habe dann in der front_content.php einfache Messungen betreffend der Ausführungszeit gemacht.

Das Problem liegt in der /contenido/includes/frontend/include.front_content.php.
In der Zeile: 724 wird die Funktion eval() ausgeführt, was bei meinem Projekt ganze 5Sekunden dauert.

Ich denke das ganze könnte noch an der Serverinfrastruktur liegen, ist ein virtual Hosting.
Hatte jemand schon mal dieses Problem? Oder kann mir jemand einen Tipp geben?

gruss
Christian

[rethus]

Aktiviere doch mal in der config.php des Mandanten die Code-Ausgabe im Frontend und schau dir mal an, was alles in der eval geladen wird.
Da sämtliche Module usw. darüber geparts werden, kann das alles sein.

PS: Im Sourcecode (core, aber auch Module) wird "schon mal" vergessen die Scriptlaufzeit sinnvoll zu beschränken. So kann es sein, das ein Objekt leer ist, aber dennoch ein ganzer Rattenschwanz von weiter parsenden Funktionen auf dem Objekt ausgeführt wird, obwohl eine kurze Abfrage nach Gültigkeit der Werte die Scriptlaufzeit drastisch verkürzen könnte.
Hand aufs Herz, es gibt sehr weniger Programmierer, die "performant" konzeptionieren/programmieren. Die meisten scheinen froh zu sein, wenn es funktioniert (da schließe ich den Kreis auch "zeitweise" hinter mir... man hat nicht immer Muße und Zeit alles optimal zu implementieren).

Wenn du also Verbesserungen in Sachen Performance hast, poste Sie ins Forum oder in den Issue-Tracker. Die werden bestimmt aufgenommen.

[chnussbaumer]

Hallo
Danke für den Tipp. Ich konnte das Problem eingrenzen. Anscheinend sind zwei Module welche eine Liste darstellen einfach zu langsam.
Ich werde diese umschreiben und ein eigenes SQL-Query verwenden. Zur Zeit verwende ich die Contenido Klassen dafür.

Ausserdem ist mir noch folgendes aufgefallen:
1) Wenn in einem Module HTML-Code im Output verwendet wird ist die Ausführungszeit langsam. Wenn man das ganze z.Bsp. mit einem Smarty - Template macht, ist es massiv schneller.

2) Leere Container in einem Template werden extrem langsam geparst.

gruss
Christian

[mattmarr]

Hi!

Ich habe ebenfalls ein massives Problem mit der Ladezeit in z.b. Contentido 4.9.8.
Bei mir tritt das Problem nur beim ersten Aufruf auf. Da kann es schonmal 20 Sekunden oder mehr dauern bis die Seite aufgebaut ist. Danach funktioniert jeder klick normal schnell.

Habe bereits Module geprüft, Datenbankausgaben geprüft und so weit mir möglich optimiert diverse Debugausgaben ausgeben lassen.
Da das Problem nur beim ersten aufruf der Seite auftritt, vermutete ich einen CronJob oder ähnliches dahinter. Scheint aber auch nicht der Fall.

Kurz gesagt, ich kann das Problem nicht lokalisieren was die Bremse ist.


Wäre echt genial, wenn wir das in den griff bekommen würden mit den Geschwindigkeitseinbrüchen der 4.9er Reihe.


Gruß
Matthias

[rethus]

Ausserdem ist mir noch folgendes aufgefallen:
1) Wenn in einem Module HTML-Code im Output verwendet wird ist die Ausführungszeit langsam. Wenn man das ganze z.Bsp. mit einem Smarty - Template macht, ist es massiv schneller.

2) Leere Container in einem Template werden extrem langsam geparst.

Danke Christian, das ist extrem wertvolles Feedback. Vielleicht lohnt es sich für diese Geschichte mal ein Ticket zu öffnen.

Ihr beide könntet ja eure Page mal mit dem Profiler von Xdebug testen und den CacheGrind hier posten. So kann man Flaschenhälse verlässlich aufspüren und beheben. Xdebug (Profiling) in Verbindung mit KCachegrind kann ich jedem der mit Performanceproblemen zu kämpfen hat wärmstens Empfehlen. Dort siehst du wie viel Rechenzeit real auf welchen Prozessen liegt... man findet so schnell raus, ob z.B. Schleifen unsauber programmiert wurden, oder unnötig aufgerufen werden.

@mattmarr: Ist das eine große Page, die bei dir in die Knie geht? Wie groß wäre die gezipt?

[mattmarr]

Hallo rethus!

@mattmarr: Ist das eine große Page, die bei dir in die Knie geht? Wie groß wäre die gezipt?

jup, ist keine kleine Page. Das ist aber nicht die einzige Seite die solche Einbrüche hat.

Den Tipp mit XDebug werde ich mal bei gelegenheit anschauen. Habe damit so noch nichts zu tun gehabt. Wenn was neues habe melde ich mich wieder.



Gruß
Matthias

[rethus]

Vielleicht auch hier ein kurzer Verweis auf diesen Artikel, über den ich gerade wegen stress mit dem Navi-Modul gestolpert bin: http://fischerlaender.de/php/php-create ... efaehrlich

Diese Funktion sollte gegen "normale" Funktionsaufrufe ersetzt werden, vor allem in der Navi und im AMR ware das ggf. ratsam.
Verwendet wird die Funktion hier:

Screenshot_002_20151111.png (5.79 KiB) 5318 mal betrachtet

@4fb: Könnt Ihr das ggf. mal prüfen?

[mattmarr]

Hallo Christian!

Das Problem liegt in der /contenido/includes/frontend/include.front_content.php.
In der Zeile: 724 wird die Funktion eval() ausgeführt, was bei meinem Projekt ganze 5Sekunden dauert.

Kann das Problem von meiner Seite aus bestätigen (con4.9..
Ich hab beim ersten Aufruf wartezeiten von bis zu 26 Sekunden bei einer größeren Seite.
Alles läuft flott bis zur eval()-Zeile aus der Datei /contenido/includes/frontend/include.front_content.php.
Irgendwas läßt die eval()-Funktion enorm ins schleudern kommen. Das ist aber komischerweise nur beim ersten aufruf der Seite. Mache ich danach erneut einen Reload, ist die Seite flott da. Daher liegt meine vermutung, das vorher bereits irgendwas nicht rund läuft beim vorbereiten des $code. Die leeren CMS_CONTAINER eines Layouts habe ich mittlerweile ebenfalls in Verdacht.

Code: Alles auswählen

                // Write html output into output buffer and assign it to an
                // variable
                ob_start();
                eval("?>\n" . $code . "\n<?php\n");
                $htmlCode = ob_get_contents();
                ob_end_clean();

                // Process CEC to do some preparations before output
                $htmlCode = cApiCecHook::executeAndReturn('Contenido.Frontend.HTMLCodeOutput', $htmlCode);

                // Print output
                echo $htmlCode;
            }

Gruß
Matthias

[rethus]

Wenn du kein xdebug-Profiling machen möchtest, mach doch die Semiprofessionelle aber alt bewährte Methode nach dem Ausschlussverfahren:

Mach eine neue Vorlage, wo kein Modul drin ist... testen!
Dann nach und nach die Module zuschalten ... testen...testen...testen!

Im Idealfall wirst du bei dem Zuschalten eines bestimmten Moduls das Problem haben, beim Abschalten ist es wieder weg... voila, du hast dein Problem eingerenzt

[mattmarr]

Wenn du kein xdebug-Profiling machen möchtest, mach doch die Semiprofessionelle aber alt bewährte Methode nach dem Ausschlussverfahren:

Danke für den Tipp. Das Ausschluß erfahren hab ich bereits hinter ihr. Sowohl mit Module als auch ohne. Immer das selbe. Erstes laden nach einer gewissen Zeit sorgt für über 20 Sekunden Ladezeit. Danach wie gewohnt sehr schnell.

Wie gesagt, könnte ich das Problem bis zur eval() - Funktion zurückverfolgen.

Wenn es meine Arbeitszeit zulässt, werde ich weiter forschen.


Gruss
Matthias

[frederic.schneider_4fb]

Guten Tag,

ich habe mir das angesehen. Nach Rücksprache mit unserem Chef-Entwickler nehmen wir uns das für Version 4.9.10 vor, da wir in der 4.9.9 absofort nur noch kritische Fehler berücksichtigen wollen.

[mattmarr]

Hallo Frederic!Q

ich habe mir das angesehen. Nach Rücksprache mit unserem Chef-Entwickler nehmen wir uns das für Version 4.9.10 vor, da wir in der 4.9.9 absofort nur noch kritische Fehler berücksichtigen wollen.

Danke für die Rückmeldung das sich das mal jemand von den Profis anschaut.
Ich werde am Wochenende auch nochmal nachschauen. Vielleicht finde ich ein paar weitere Infos die helfen könnten.




Gruß
Matthias

[chnussbaumer]

Hallo zusammen

Ich habe bei meiner Seite die leeren Container mit einem einfachen Modul bestückt. Dieses gibt ein leeres Smarty - Template zurück. Hat immerhin 200ms gebracht.
Jetzt läuft die Seite ganz ok. Wobei die Time2FirstByte immer noch bei 900ms liegt. Also immer noch ziemlich langsam.
Ich werde, sobald ich ein Zeitfenster habe versuchen das Problem weiter einzugrenzen.
Alternativ versuche ich bei meiner Seite das Caching von Modulen mittels Smarty zu realisieren. Smarty hat ein wirklich kluges und schnelles
Cache - Management.

Danke an 4fb für die Unterstützung.

Grüsse aus der Schweiz

[mattmarr]

Hallo!

Ich konnte leider bisher noch nichts weiter ausfindig machen um das Problem noch weiter einzugrenzen
Das Problem ist echt nervig. Vor allem wenn ein Projekt Online gehen soll und die Seite vorab zum Kaffetrinken einlädt.

Wäre echt gut wenn es Idee gibt um dieses kurzzeitg mit eim Fix vorerst korrigieren.



Gruß
Matthias
P.s.: mir gehen die Haare aus, die noch grau werden könnten.

[Oldperl]

Hallo Matthias,

ich denke nicht das es da eine...

... Idee gibt um dieses kurzzeitg mit eim Fix vorerst korrigieren.

Das Problem ist System-bedingt und immer vorhanden, fällt jedoch extrem auf "schwachbrüstigen" Servern oder vHostings auf. Der Grund ist eigentlich auch recht einfach nachvollziehbar. Beim 1. Aufruf wird erst einmal alles zusammengesucht und entsprechend in mehreren Durchgängen geparst, wobei preparsed Versionen der Seite im Cache abgelegt werden. Daher ist dann auch der 2. Aufruf schneller, wenn, ja wenn die preparsed Cache-Datei vorhanden, kein Zeiger zum erneuern des Cache gesetzt oder eine mögliche Cache-Zeit nicht abgelaufen ist.

Alternativ versuche ich bei meiner Seite das Caching von Modulen mittels Smarty zu realisieren. Smarty hat ein wirklich kluges und schnelles
Cache - Management.

Die Aussage zu Smarty stimmt auch nur bedingt. Ja, durch die Nutzung von Smarty erscheint die Seite schneller, wobei das auch nur bedingt stimmt. Der allererste Aufruf sollte sogar noch etwas langsamer sein als ohne Smarty. Erst dann greift bei jedem Aufruf das Caching von Smarty, sprich, auch wenn ich den Contenido-Cache leere bleiben die Smarty-Templates der Module gecachet und dadurch erscheint der erneute "erste" Aufruf der Seite schneller.

Optimierungsmöglichkeiten gibt es aus meiner Erfahrung heraus an mehreren Stellen. Primär sollte man sich sicherlich den Core vornehmen, denn gerade hier könnte man durch Optimierung von DB- und Datei-Zugriffen und einen saubereren Umgang mit PHP-Objekten und Resourcen viel erreichen. Auch eine Optimierung des Datenbank-Servers und dessen Einstellungen muss man in Betracht ziehen (sofern möglich).
Jedoch kann auch der Administrator/Entwickler der Webseite an etlichen Stellen optimieren. Hier seien als Beispiel Code-Optimierungen von Modulen und Plugins aber vor Allem die Vermeidung von ungenutzten Containern im Layout genannt. Allein diese Maßnahmen können das Parsing beim 1. Durchlauf signifikant beschleunigen.

Ich selbst habe mich mittlerweile darauf spezialisiert 4.9er Auftritte in Richtung Performance und Sicherheit für meine Kunden zu optimieren, jedoch empfehle ich bei "günstigen", und dadurch in den meisten Fällen eben "schwachbrüstigen", Webs dann auch irgendwann entweder ein Upgrade oder den Verbleib bei einer 4.8er Version. Denn diese Optimierung ist zumeist Zeit- und damit eben auch Kostenintensiv.

Alles in Allem muss man aber sagen das die 4.9er-Reihe durch ihre inneren Struktur mehr Resourcen benötigt, wobei der immer vorgebrachte Mehrwert für den Anwender nur einen sehr kleinen Anteil daran hat. Hauptgrund ist für mich vielmehr der grundsätzliche Strukturumbau mit dem Mehraufwand bei Dateien und der, wenn nicht optimiert, schlechteren Performance von InnoDB gegenüber MyIsam.

Gruß aus Franken

Ortwin