[con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
mattmarr
Beiträge: 361
Registriert: Mo 3. Aug 2009, 14:11
Kontaktdaten:

[con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von mattmarr » Di 13. Feb 2018, 12:23

Hallo an Alle!

Ich habe da mit einem aktuellen Projekt ein riesen Problem.

Es existiert ein Modul, im dem z.b. bis zu 5stk CMS_LINKEDITOR[] -Anfasser verbaut sind.
Funktioniert ja auch alles sehr gut und das schon seit Monaten.
Nun habe ich mit dem aktuellen Projekt einen drastischen Einbruch der Leistung im Backend. Nur im Backend!
Will ich einen Artikel bearbeiten, dauert es bis zu mehreren Sekunden, bis ich weiter Editieren kann. Bei jedem Speichern.
Nehmen ich nur die CMS_LINKEDITOR[]-Anfasser aus dem Modul, ist alles wie gehabt, schnell.

Ich hab dann mal ein wenig geforscht und bis schliesslich bei der Funktion buildDirectoryList() (https://api.contenido.org/con4911/sourc ... ml#279-328) fündig geworden.
Diese Funktion wird jedesmal aufgerufen, wenn der CMS_LINKEDITOR[] irgendwo im Layout eingesetzt wird. Das Problem bei der Funktion ist, das bei jedem Aufruf, aufs neue, die Verzeichnisstruktur ausgelesen wird. Je nach umfang der Dateiverwaltung, kann das schon einiges an Zeit in Anspruch nehmen.

Es wäre gut wenn es dafür ein schnelle Lösung geben könnte.
Bis auf weiteres habe ich im Quellcode der Datei class.content.type.linkeditor.php zeile 229-232 ausgeklammer.

Code: Alles auswählen

       $templateTabs->set('d', 'TAB_CONTENT', $this->_generateTabInternal());
        $templateTabs->next();

        // create code for file tab
//        $templateTabs->set('d', 'TAB_ID', 'file');
//       $templateTabs->set('d', 'TAB_CLASS', 'file');
//        $templateTabs->set('d', 'TAB_CONTENT', $this->_generateTabFile());
//      $templateTabs->next();

        // create code for basic settings "tab" - these settings are actually
        // visible any time
        $templateTabs->set('d', 'TAB_ID', 'basic-settings');

Gruß
Matthias

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von Oldperl » Di 13. Feb 2018, 15:32

Servus,

eine schnelle Lösung ist da nicht drin. Das erstellte Array sollte gecacht werden, wobei sich noch die Frage stellt an welcher Stelle man cacht. Das kann man sowohl in der Linkeditor-Klasse für das gesamte Auswahlfeld oder eben in der Elternklasse nur für das Array.
Ich denke, dass sollte man unter den Entwicklern nochmal besprechen.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

mattmarr
Beiträge: 361
Registriert: Mo 3. Aug 2009, 14:11
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von mattmarr » Di 13. Feb 2018, 16:34

Hallo Ortwin!
Oldperl hat geschrieben:
Di 13. Feb 2018, 15:32
eine schnelle Lösung ist da nicht drin. Das erstellte Array sollte gecacht werden, wobei sich noch die Frage stellt an welcher Stelle man cacht.
Nach einer vernünftigen Stelle habe ich auch schon gesucht und vorerst aufgegeben. Ist doch etwas komplizierter als es ausschaut. :)


Gruß
Matthias

mattmarr
Beiträge: 361
Registriert: Mo 3. Aug 2009, 14:11
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von mattmarr » Mi 21. Feb 2018, 14:12

Hallo!

Es wäre echt klasse, wenn dieses Problem noch in die kommende 4.9.13 einfließen könnte.
Habe gerade bemerkt, das es echt nervend sein kann und auch die Kunden sehr ungeduldig werden lässt.


Gruß
Matthias

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von Faar » Mi 21. Feb 2018, 14:51

Neben dem Contenido Problem würde ich auch mal schauen, wie die Datenbankbelastung live ausschaut, wenn das aufgerufen wird.
Ebenso bei PHP, was sich da so im Speicher tut.
Eventuell ist da auch eine Engstelle, die durch Einstellungen beseitigt werden könnte.

Nur so eine Idee :|
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

mattmarr
Beiträge: 361
Registriert: Mo 3. Aug 2009, 14:11
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von mattmarr » Mi 21. Feb 2018, 15:45

Hallo Faar!
Faar hat geschrieben:
Mi 21. Feb 2018, 14:51
Neben dem Contenido Problem würde ich auch mal schauen, wie die Datenbankbelastung live ausschaut, wenn das aufgerufen wird.
Ebenso bei PHP, was sich da so im Speicher tut.
Eventuell ist da auch eine Engstelle, die durch Einstellungen beseitigt werden könnte.
Gute Idee, habe ich schon alles geprüft.
Problem tritt nur auf wenn in der Dateiverwaltung viele Ordner und Dateien sich befinden. Contenido versucht bei jedem CMS_IMGEDITOR und CMS_LINKEDITOR, und vermutlich weitere, die Order immer aufs neue zu identifizieren.
Ich habe jetzt erstmal eine absolute provisorische Cachefunktion in besagte Datei eingebaut. Jetzt rennt die Seite im Backend.


Gruß
Matthias

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von Faar » Mi 21. Feb 2018, 17:57

Hallo Matthias!
Da läuft einiges ab bei der Backend Anzeige. Kein Wunder gibt es Probleme falls alle Dateiordner nochmal durchlaufen werden.
Zeile 703 könnte wahrscheinlich Dein Problem verursachen: https://api.contenido.org/latest/source ... r.html#703
Praktisch könnte man die Daten aus der DB beziehen, statt aktuell die Daten aus dem Verzeichnis auszulesen.
Eine Art Parameter wäre gut, mit dem man angeben könnte, ob DB Daten oder Live-Daten genommen werden sollen.
Das ist im Backend doof, weil der Editcode mit generateEditCode() ein generateTabFile() aufruft das wiederum dieses getUploadFileSelect() aufruft, das alle Verzeichnisse und Dateien durchgeht.

Praktischerweise sollte das erst passieren, wenn wirklich der Edit-Button eines CMS_LINKEDITOR betätigt wird und nicht schon bei der Backendansicht im Editmode.
Aber das ändert an den vielen Verzeichnissen nichts. Da hülfe ein Cronjob, der regelmäßig nachts die Verzeichnisse in der DB aktualisiert und dort in einer Tabelle alle Daten ausgelesen werden.
Andererseits ist Contenido nicht für Massenverarbeitung ausgelegt, das war nie Sinn und Ziel von Contenido.
Hier müsste es andere Klassen und Module geben, die darauf optimiert sind.
:shock:
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von Oldperl » Mi 21. Feb 2018, 17:58

Servus,
mattmarr hat geschrieben:
Mi 21. Feb 2018, 14:12
Es wäre echt klasse, wenn dieses Problem noch in die kommende 4.9.13 einfließen.
mattmarr hat geschrieben:
Mi 21. Feb 2018, 15:45
Ich habe jetzt erstmal eine absolute provisorische Cachefunktion in besagte Datei eingebaut. Jetzt rennt die Seite im Backend.
Na dann lass doch mal sehen was du da gecoded hast. Vielleicht hält es ja noch Einzug in 4.9.13.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

mattmarr
Beiträge: 361
Registriert: Mo 3. Aug 2009, 14:11
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von mattmarr » Mi 21. Feb 2018, 22:18

Faar hat geschrieben:
Mi 21. Feb 2018, 17:57
Andererseits ist Contenido nicht für Massenverarbeitung ausgelegt, das war nie Sinn und Ziel von Contenido.
Warum nicht?
Wir haben bei den Kunden auch keine große Massenverarbeitung. Aber es gibt Kunden die wollen halt ein paar Galerien anbieten oder andere Unterseiten die einem Blog ähneln. Da können schonmal ein paar News-Artikel oder Hunderte Bilder pro Jahr zusammenkommen. Das darf aber kein mächtiges System wie Contenido so in die Knie zwingen.
Es gibt einige stellen, die hier bereits seit Monaten angesprochen wurden, inkl Lösungsansätze der Benutzer, wo man ansetzen kann. Aber irgendwie hab ich den verdacht, das Ideen andere User nicht wirklich einfließen um das System zu optimieren.
Version 4.9.x hat richtig klasse Ansätze. Es harkt an einfachen aber sehr wichtigen stellen. Wo genau, kann man hier im Forum an den diversen Themen gut nachlesen.

Ich mag und werde auch in Zukunft nicht auf Contenido verzichten, da es ein richtig gutes System ist, das Kunden sofort verstehen. Aber es kann doch nicht sein, das ich am Core-System immer mehr optimieren muss damit auch einfache sachen gut laufen. Ja, jetzt kommt bestimmt wieder das Thema: Melde deine Ideen doch im GIT. Ich hatte vor Monaten hier auch schonmal nachgehackt, da ein Login nicht möglich ist, trotz Account. Selbst das zurücksetzen des Passworts funktioniert nicht. Es kommt leider keine Reaktion seitens des Betreibers. Sonst würde ich gerne Optimierungen im GIT vorschlagen.

So, genug gemeckert.:)
Freue mich auf gegengemecker. :roll:


Gruß
Matthias

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von Faar » Do 22. Feb 2018, 11:20

mattmarr hat geschrieben:
Mi 21. Feb 2018, 22:18
Faar hat geschrieben:
Mi 21. Feb 2018, 17:57
Andererseits ist Contenido nicht für Massenverarbeitung ausgelegt, das war nie Sinn und Ziel von Contenido.
Warum nicht?
Contenido ist ein strukturiertes CMS und Wordpress ein Blog aber beide sind nicht für Massenverarbeitung gebaut worden, wie z.B. Facebook oder Twitter es sind.
Da müsste der ganze Core anders aufgebaut sein, andere Technologien verwendet werden und die Datenbank ganz anders aussehen.
Ich hatte mal einen Wordpress-Multiblog eingerichtet, der völlig abkackte, als die Inhalte (große Videos) eingepflegt wurden.
Mit Contenido ging es dann aber nach dem Umzug.
Grund war der, dass Wordpress versuchte, eine Übersicht darzustellen indem es die Inhalte verwendete.
Bei Contenido hatte ich es dann so aufgebaut, dass es kleine und statische Vorschauinhalte gab und erst auf der entsprechenden Seite das Video eingebunden wurde.

Nun, das erinnert vielleicht irgendwie an dein Problem?
Würde Contenido statt das Verzeichnis live auszulesen nur vorbereitete und begrenzte Inhalte aus der DB anzeigen, wäre es schwupps aufgebaut.
Das hat den Nachteil, dass vorbereitete Inhalte nie ganz aktuell sein können.
Siehe auch Unterschied zwischen Blog und strukturiertes CMS.

Alleine die Denkweise bei Contenido ist ganz anders als es bei Massenverarbeitung sein müsste.
Bei Contenido wird strukturiert und verschachtelt und abstrahiert was geht.
Das ist bis zu einem Break-Even-Point gut, aber irgendwann sind die Ressourcen ausgeschöpft und das stetig bei Massenverarbeitung.
Mehr Speicher hilft fürs erste, sowohl für DB als auch für PHP.
Aber schaue ich mir die DB-Abfragen von Contenido an, dann kräuseln sich mir die Haare, wenn ich an Performance denke.
Die Contenido DB wurde normalisiert, Redundanz vermieden.
Ich aber habe damals in einem Portal extra Redundanz eingebaut und die Normalisierung zurückgeschraubt.
http://www.datenbanken-verstehen.de/dat ... datenbank/

Man kann aber Zwischenwege gehen, mit Cronjobs und temporären Tabellen oder solchen wie der Tree-Tabelle in Contenido.
Auch Klassen und Funktionen und Plugins und Module und vielleicht Chains können einiges bewirken, indem sie Daten anders beschaffen oder anders aufbereiten.
Aber es gibt Kunden die wollen halt ein paar Galerien anbieten oder andere Unterseiten die einem Blog ähneln.
Wordpress ist ein Blog, das zeigt sich durch die Kern-Engine, die große Schleife und die Art, wie die Daten abgespeichert sind.
Hier kann man auch die DB und die Tabellen entsprechen optimieren, dass sie für einen Blog gut arbeiten.
Aber schau dir mal die Medienverwaltung an, wenn es da tausende Bilder gibt?
Verzweiflung ist noch milde ausgedrückt.

Es gibt Bildergalerien, wie meine DF-Galerie, die holen sich die Bilder aus einem Verzeichnis und alle Bilder die da drin sind, werden angezeigt. Die User müssen lediglich im Backend die Bilder entsprechen in ein Verzeichnis hoch laden. Das können sie intern machen oder über FTP. Bei FTP allerdings muss man nochmal ins Backend und in die Dateiverwaltung und dieses Verzeichnis anklicken, damit Contenido die Bilder scannt und die Metadaten in die DB lädt.
Es liegt an der Programm-Architektur der Galerie, wie die Daten zustande kommen.
Hat man eine Galerie, die beliebige Bilder einzeln auswählen lässt, kann es eng werden.
Und die Bildgröße spielt auch eine nicht kleine Rolle, denn jedes einzelne Bild muss ins PHP und dort verarbeitet werden.
Vollauflösende Bilder sind dafür ein NoGo.
Darum habe ich auch eine Chain geschrieben, die Bilder beim Upload schon verkleinert, damit Internet taugliche Bilder im Dateiverzeichnis stehen.
Contenido kann nichts dafür, wenn 50MB Bilder hochgeladen werden.
Wenn das so sein soll, braucht es ordentlich RAM und schnelle Prozessoren beim Server.
Da können schonmal ein paar News-Artikel oder Hunderte Bilder pro Jahr zusammenkommen. Das darf aber kein mächtiges System wie Contenido so in die Knie zwingen.
Tut es eigentlich auch nicht.
Aber wenn große Datenmengen RAM des Servers für PHP verbrauchen und dann noch die DB auf das gleiche RAM angewiesen ist, dann wird es schnell eng. Aus dem Grund trennt man DB und Webserver bei Seiten mit Massenverarbeitung.
Contenido und 4fb machen das sicher auch so bei großen Projekten.
Aber es kann doch nicht sein, das ich am Core-System immer mehr optimieren muss damit auch einfache sachen gut laufen.
Galerien sind keine einfache Sache. Hast Du mal geschaut, wie viel RAM so ein 10MB jpeg Bild im Verabreitungsprozess verbraucht?
10 MB zehnfach komprimiert, dann bei der Verarbeitung nochmal mehrere Kopien im RAM und dann eine DB die bei Sortierungen Tabellen mehrfach spiegelt um sie sortieren zu können und dann noch Zugriffe auf den Server um Files auszulesen.
Ab dem Moment, wo der Server wegen DB oder PHP auf die Platte auslagern muss, hast du verloren. Dann geht die Performance extrem in die Knie.
Nimm mal einen Server mit SSD Platte und schau was passiert.
Wenn das Problem dann gelöst ist, wurde vermutliche die Festplatte zur Auslagerung genutzt, weil der RAM nicht ausreichte.
Freue mich auf gegengemecker. :roll:
:D

Schau mal lieber was dein Server macht, ob da riesige Bilder sind, ob der RAM groß genug ist und wechsle im Zweifel auf SSD-Server.
Und sollte da alles grün sein und dein Contenido immer noch zu lahm sein, dann würde ich das Modul anders aufbauen.
Das dürfte alles schneller gehen als das Contenido im Kern das geändert bekommt. das hängt von zu vielem ab.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

samse
Beiträge: 48
Registriert: Di 1. Sep 2015, 09:05
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von samse » Do 22. Feb 2018, 15:18

Hi Matthias

Ich habe genau das gleiche Problem in einem Projekt. Mein Lösungsvorschlag für das Problem wäre, dass die Verzeichnisse nur einmal gelesen werden und für alle CMS_IMAGEEDITOR verwendet werden, oder aber wenn man auf den CMS_IMAGEEDITOR-Button klickt, via Ajax die Verzeichnisse geladen werden.
Ich habe jetzt erstmal eine absolute provisorische Cachefunktion in besagte Datei eingebaut. Jetzt rennt die Seite im Backend.
Könntest du diesen Code hier posten, sodass ich mir das anschauen kann und vielleicht auch bei mir einbauen?

Grüsse
Samse

mattmarr
Beiträge: 361
Registriert: Mo 3. Aug 2009, 14:11
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von mattmarr » Do 22. Feb 2018, 16:07

samse hat geschrieben:
Do 22. Feb 2018, 15:18
Könntest du diesen Code hier posten, sodass ich mir das anschauen kann und vielleicht auch bei mir einbauen?
Im Anhang dieser Nachricht ist die class.content.type.abstract.php.
Darin findest Du ein paar zeilen die mit "// mm" markiert sind. Diese einfach in deine class.content.type.abstract.php einfügen.

Die Datei class.content.type.abstract.php findet man imden Ordner contenido/classes/content_types.

Wie schon geschrieben. Das ganze ist nur eine fixe Notlösung weil 3 Kunden probleme gemacht habe die letzte Tage. Für was finales muss man mal genauer schauen.


Gruß
Matthias
Dateianhänge
class.content.type.abstract.php.zip
(3.5 KiB) 138-mal heruntergeladen

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von Faar » Do 22. Feb 2018, 16:30

Hallo Matthias,

hab den Code angeschaut und es ist leider nur eine Notlösung, das stimmt, aber wenn es erstmal so funktioniert, ist doch ok.
So wie es aussieht, wird zur Laufzeit einmal die Cache-Variable erzeugt und solange die gefüllt ist, wird nicht mehr neu das Verzeichnis durchsucht.
Die Variable hält sich so lange wie der Backenduser im Programm ist?
Kann das nicht zu einem Problem führen, wenn der User im Datei-Verzeichnis etwas neues hinzufügt und ihm immer noch der alte Zustand angezeigt wird?
Gibt es einen Chain-Hook beim System Bereinigen, der auch gleich diese Variable leeren würde?
Sonst müsste sich der User ausloggen und wieder einloggen um den neuen Verzeichnisbaum zu sehen.

Aber der Ansatz an dieser Stelle ist gut, meiner Meinung nach, da könnte vielleicht auch Freddie und Oldperl was dazu sagen. :?

:shock:
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

samse
Beiträge: 48
Registriert: Di 1. Sep 2015, 09:05
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von samse » Mo 26. Feb 2018, 11:17

Hi Zusammen

Ich habe mir den Code von Matthias angeschaut (Vielen Dank dafür!) und ihn ein wenig überarbeitet. Mir hat die globale Variable im File nicht gefallen :D. Habe diese mit der "cRegistry::setAppVar" Funktion ersetzt, welche ich im "startup.php" gesetzt habe (mir ist kein besserer Ort dafür eingefallen). Den restlichen Code von Matthias habe ich fast 1:1 übernommen und einfach ersetzt durch "cRegistry::getAppVar".

Der Performance-Steigerung ist unglaublich! Seite welche vorhin 11 Sekunden zum Laden gebraucht hat, ist nun in weniger als einer Sekunde da :!: :!:

Auch besteht kein Problem mit dem Datei-Verzeichnis, da das Caching erst nach dem ersten Element passiert, sodass immer beim ersten Element alle Verzeichnisse neu geladen werden und die anderen Elemente übernehmen dies.

Angefügt findet ihr meinen Code (Kommentare mit // samse). Wäre schön, wenn dieser in der nächsten Contenido Version Einzug finden würde.

Grüsse
Samse
Dateianhänge
startup.php.zip
(2.83 KiB) 90-mal heruntergeladen
class.content.type.abstract.php.zip
(3.42 KiB) 100-mal heruntergeladen

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: [con 4.9.12] riesen Problem CMS_LINKEDITOR[]

Beitrag von Oldperl » Mo 26. Feb 2018, 11:45

Servus,

Caching ist hier sicherlich der richtige Ansatz. Auch ein globaler Zugriff während der Laufzeit macht Sinn. PHP bietet da bei OOP aber bereits Möglichkeiten ohne das verpönte "global" zu nutzen oder auf die Registryklasse zuzugreifen. Auch eine Definition in der startup.php ist für mich der falsche Platz, hier sollte man bedenken, das diese Datei nur für wirklich globale, sprich immer im System benötigte, Instanzen und Vorgaben Sinn macht.
Wir müssen das einfach nochmal richtig überdenken und vor Allem testen bevor es dafür eine Lösung geben wird, vor Allem auch im Hinblick auf skalare Systeme, da auch ein Caching irgendwann bei den Ressourcen ein Problem darstellen kann. Mir schwebt da eher eine gemischte Lösung zwischen Speicher- und File-Cache vor. Auch gibt es ja im Core bereits eine Cache-Lösung, die man gegebenenfalls nutzen kann und sollte.

Trotzdem danke für die tollen Vorschläge, sie adressieren das Problem und zeigen den Lösungsweg auf.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

Antworten