[con4.9.8] Dateiverwaltung Thumbs

[mattmarr]

Hallo!

Kann es sein, das im Backend die Dateiverwaltung sowas von Extrem langsam geworden ist?
Ich hab die Vermutung, das bei jedem Aufruf eines Ordners oder die Dateiverwalung selbst, die Thumbnails jedesmal neu berechnet werden.

Kann das wer Prüfen?



Gruß
Matthias

[mattmarr]

Nachtrag:

Kann es sein, das es ein generelles Problem beim auslesen von einem Ordner/Kategorie gibt?

Ich habe mir in die Datei include.upl.files_overview.php in der "While($item = $uploads->next())" Schleife einen Helfer "echo '.';" eingebaut.
Dieser gibt mir dann für jede Datei, ein "." aus.
Anschlissend gehe ich in die Dateiverwaltung und rufe meinen Ordner auf. Dort sind z.b. 50 Dateien drin. Es werden mir auch 50 Punkte durch meinen Helfer ausgegeben.
Jetzt aber stelle ich "Dateien pro Seite" auf "10".
Was zeigt mein Helfer mir dann an?
Genau, auch 50 kleine Helfer.

Das erklärt natürlich das Problem.

Warum werden sowohl in der Dateiverwaltung (cApiUploadCollection) als auch bei den Artikeln (cArticleCollector) erst alle Dateien/Artikel einer Kategorie ausgelesenen um dann anschlissend nur ein paar davon auszugeben?

Das ist kein Wunder, das Contenido im laufe der Zeit, umso mehr Artikel/Dateien sich im System befinden, in die Knie gewzungen wird.


Gruß
Matthias

[Oldperl]

Hallo Matthias,

diese Sache mit den Api-Klassen zieht sich durch alle Contenido Versionen, den Grund kennt wohl nur der Entwickler der die genericdb-Klasse entwickelt hat, oder es liegt an der Doku zur Klasse. Das sind beispielsweise auch die Gründe dafür, das im Bereich Userverwaltung (gerade bei den Frontenduser) Contenido Probleme hatte. Beim cArticleCollector liegt es dann an einem Denkfehler in der Struktur und dem internen Handling der Klasse. Offensichtlich ist da noch viel Potential zur Performanceoptimierung. Ich habe das für meine CL-Version in Teilen bereits geändert. Ob ich das auch für 4.9 mache weiß ich, mangels Zeit, noch nicht.

Gruß aus Franken

Ortwin

[mattmarr]

Hallo Ortwin!

Offensichtlich ist da noch viel Potential zur Performanceoptimierung. Ich habe das für meine CL-Version in Teilen bereits geändert.

Da liegt definitiv noch Potenzial drin. Denn auch ich habe schon die Classe cArticleCollector optimiert ohne groß was ändern zu müssen. Und siehe da, die Seite rentt vieeeeeel besser.

Jetzt schau ich mir erstmal cApiUploadCollection genauer an. Da scheint genau der selbe denkfehler drin zu sitzen. Mal sehen was ich da noch rauskitzeln kann.



Gruß
Matthias

[frederic.schneider_4fb]

Das ist in der Tat ein Problem. Ich habe in dem Punkt erst vor wenigen Wochen die Übersicht von Frontend-Usern verbessert. Dort wurde auch zu jedem Zeitpunkt alles geladen und wenn man mal testweise 1.000 Frontend-Benutzer eingetragen hatte, lud die Seite merklich langsam. Das ganze war mit einer Zeile erledigt:

Code: Alles auswählen

$oFEUsers->setLimit($elemperpage * ($mPage - 1), $elemperpage);

Es gibt also durchaus Mittel und Wege, das zu verbessern (wenn auch nicht an jeder Stelle so einfach mit einer Zeile). Wir sind also dankbar über jede konkrete Anregung!

[frederic.schneider_4fb]

Bezüglich der Dateiverwaltung nehme ich das mal als Ticket auf:

• Abfrage aller Einträge, obwohl über das Paging die Anzahl begrenzt wurde
• Jedesmal Neugenerierung der Thumbnails

Letzteres sollte eigentlich nicht passieren, dafür gibt es ja eine Thumbnail-Cache

[mattmarr]

Hallo Frederic!

Bezüglich der Dateiverwaltung nehme ich das mal als Ticket auf:

• Abfrage aller Einträge, obwohl über das Paging die Anzahl begrenzt wurde

Wäre echt nett, wenn ihr das fix korrigieren könntet, das es einige Contenido installtionen von uns betrifft.
Habe mir eben die Class cApiUploadCollection mal genauer angeschaut aber keine wirkliche lösung gefunden, da die reihenfolge, wie die Classe funktioniert, doch sehr irretierend aufgebaut ist.



Gruß
Matthias

[McHubi]

Ich habe in dem Punkt erst vor wenigen Wochen die Übersicht von Frontend-Usern verbessert.

Heißt, in der aktuellen 4.9.8 umgesetzt?

[frederic.schneider_4fb]

Ich habe in dem Punkt erst vor wenigen Wochen die Übersicht von Frontend-Usern verbessert.

Heißt, in der aktuellen 4.9.8 umgesetzt?

Genauso ist es. Das ist noch in die Version 4.9.8 eingeflossen.

[frederic.schneider_4fb]

Wäre echt nett, wenn ihr das fix korrigieren könntet, das es einige Contenido installtionen von uns betrifft.

Ich schaue mal, ob ich ggf. dazu noch heute komme. Ansonsten in zwei Wochen, da ich nächste Woche "leider" im Urlaub bin.

Habe mir eben die Class cApiUploadCollection mal genauer angeschaut aber keine wirkliche lösung gefunden, da die reihenfolge, wie die Classe funktioniert, doch sehr irretierend aufgebaut ist.

Die Collection-Klasse stellt ja auch lediglich die Funktionen zur Verfügung. Die ist nicht das Problem. Entscheidend ist das Handling in den Include-Dateien. Sprich: Die Datei include.up_files_overview.php ist das "Übel" . Das Paging wird bislang lediglich auf die Darstellung und nicht auf die Sql-Abfrage (= auf die Collection) angewendet. Wie geschrieben: Vllt. widme ich mich dem schon nachher, sonst in zwei Wochen .

[McHubi]

Daumen hoch!
Wenn Du Dir die "include.up_files_overview.php" ohnehin anschaust, wirf doch bitte noch mal einen Blick hierdrauf: http://forum.contenido.org/viewtopic.php?f=92&t=35372
Ja, ist nichts 100%iges aber in vielen Fällen beim tiny-generierten Content hilfreich.

[mattmarr]

Hallo Frederic!

Wie geschrieben: Vllt. widme ich mich dem schon nachher, sonst in zwei Wochen .

Ich drücke feste die Daumen, das Du noch heute dazu kommst.



Gruß
Matthias

[frederic.schneider_4fb]

Ich habe es mir eben angesehen, das ist leider viel komplizierter als gedacht:
Die Seite benötigt derzeit alle Einträge, weil ansonsten das gesamte Listensystem obsolet ist. D. h. es funktioniert dann nicht mehr die Darstellung der Seite, die Berechnung der Seitenzahl etc. pp. Ich habe dazu versucht kurzfristig eine Lösung zu finden, aber das wird leider ohne größeren Aufwand nichts. Tut mir leid . Da werde ich wohl das gesamte System umschreiben bzw. neu entwickeln müssen.

[mattmarr]

Ich habe es mir eben angesehen, das ist leider viel komplizierter als gedacht:
Die Seite benötigt derzeit alle Einträge, weil ansonsten das gesamte Listensystem obsolet ist. D. h. es funktioniert dann nicht mehr die Darstellung der Seite, die Berechnung der Seitenzahl etc. pp. Ich habe dazu versucht kurzfristig eine Lösung zu finden, aber das wird leider ohne größeren Aufwand nichts. Tut mir leid . Da werde ich wohl das gesamte System umschreiben bzw. neu entwickeln müssen.

Mein Reden.
Hatte es mir heute früh auch angesehen und auf halben wege die besagte Flinte vorerst ins Korn geworfen.



Gruß
Matthias

[rethus]

Hallo Ortwin!
Denn auch ich habe schon die Classe cArticleCollector optimiert ohne groß was ändern zu müssen. Und siehe da, die Seite rentt vieeeeeel besser.
Jetzt schau ich mir erstmal cApiUploadCollection genauer an. Da scheint genau der selbe denkfehler drin zu sitzen. Mal sehen was ich da noch rauskitzeln kann.

Schön das du eine Lösung hast, besser ist es, wenn du - der Commuity, Contenido und dir selbst [für künftige Updates] zuliebe diese Anpassungen sauber dokumentierst, und darum bittest, dass diese im Core aufgenommen werden.
Ein freundlicher 4fb mitarbeiter macht dann ein Ticket daraus, und es fließt ins nächste Release ein.

"Ich habs gelöst" bringt an der stelle keinen weiter - dich selbst auch nur mittelfristig, da du diese Anpassung dann in Zukunft nach jedem Update und auf allen verwendeten Systemen erneut einpflegen musst.
Besser Contenido als ganzes voranbringen.

Es gibt ein GIT, WIKI, Issue-Tracker - versuch mal dein Glück dich da anzumelden [für mich bekommt 4fb den Zugang nicht hin (irgendwelche Berechtigungsprobleme), aber du hast da vielleicht mehr Glück].
So kannst du die Community aktiver unterstützen.


In Sachen Performance und Contenido muss man sehen, dass Contenido arg gewachsen ist, und man deutlich merkt, wie auch 4fb enorm an Knowhow und Infrastruktur aufgebaut haben. Lob von mir dafür, dass Ihr die Kurve damit so gut bekommen habt. Aber ja, es ist viel Bedarf an Optimierung, daher haltet es doch so wie ich entsprechend der "CleanCode"-Maxime: Verlasse den Code etwas besser als du Ihn vorgefunden hast [+ poste die Optimierungen im Forum, damit Sie dauerhaft erfasst werden].