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.
Nö
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.