Newsarchiv mit über 10.000 Einträgen sprengt Speicher

[the_scrat]

Öhm, nein?

Es wird doch wohl einen Unterschied machen ob ich versuche 10.000 Einträge auf einen Schlag zu selektieren/verarbeiten oder ob ich mit einem Offset arbeite z.B. einer ID die ich bei der Abfrage mitnutze.

Wenn ich 10.000 Einträge über die Models, gemäß deiner Analyse verarbeite, kommt der o.g. Speicherverbrauch zustande.
Wenn ich jetzt hingegen in einem Durchlauf nicht 10.000 sondern nur 2000 verarbeite und 1 Minute später die nächsten 2000 (erneuter Aufruf) dann sollte hier vom 1. Aufruf nichts mehr im Speicher sein, oder irre ich mich da?
So kommt man vielleicht in Summe auf den gleichen Speicherverbrauch, aber nicht zur Laufzeit selbst und das macht den Unterschied.

Man schickt ja auch keine 10.000 E-Mails gleichzeitig raus bei einem Newsletter, sondern in kleinen "Häppchen" a 50 Stück .... vielleicht macht es dieser Vergleich besser deutlich.

[Spooky]

Wenn ich jetzt hingegen in einem Durchlauf nicht 10.000 sondern nur 2000 verarbeite und 1 Minute später die nächsten 2000 (erneuter Aufruf) dann sollte hier vom 1. Aufruf nichts mehr im Speicher sein, oder irre ich mich da?

Dazu muss die Funktion, die die Sitemap generiert, auch entsprechend so programmiert werden. Und das ist nicht ganz trivial. Und so wie du es vorschlägst, macht man das normalerweise nicht. Hier setzt man normalerweise out of core Methoden ein. Einen Vorschlag habe ich damals schon hier gebracht: https://community.contao.org/de/show...l=1#post337344

[Stranger]

Das liest sich aber anders :-)

Die Frage impliziert, dass du es anscheinend selbst nicht weißt...

Und selbst wenn es ein SELECT * FROM ist, wird es seinen Sinn haben, um nicht 15 Abfragen hintereinander zu machen (je Erweiterung oder je Einsatzort).

Hast du dazu aussagekräftige Benchmarktests gemacht? Wenn ja, wäre es prima, wenn du diese veröffentlichst. Ich denke mir, ein gutes Hosting mit gut konfiguriertem Webserver ist mehr Wert als deine Vorstellung einer Optimierung eines Models (zumindest für wahrscheinlich 95% aller Webseiten).
Wenn du natürlich eine leere PHP-Datei erstellst, dort die DB Verbindung aufbaust, 30 Datensätze selektierst und die Zeit misst und dann das gleiche mit den 30 Datensätzen über Contoa machst, dauert das immer länger. Egal ob mit SELECT * oder SELECT field1,field2 FROM etc....

Das bedeutet, du willst jedem Extension-Entwickler zusätzlich die Arbeit machen, dass er neben der eigentlichen Extension auch noch explizit angeben muss, dass Variable x,y,z in Template t1,t2,t3 zur Verfügung stehen kann? Wenn er das nicht macht, ist die Variable nicht verfügbar? Und das "nur" weil dir die Ausgabe von $this->showTemplateVars() nicht gefällt?

1. Das war eine rhetorische Frage. Nein, ich habe es nicht überprüft, aber da es ist nicht anders denkbar als SELECT * FROM
2. Nein Benchmarktests hab ich auch nicht laufen lassen, aber dass von SELECT * in den meisten Fällen abzuraten ist, steht gewiss in jedem PHP/Datenbankbuch.
Ich kann mir auch vorstellen, dass es bei anderen CMS genauso gehandhabt wird. Aber Ich dachte mir, dass ich einfach mal nachfrage nachdem mir das schon jahrelang aufgefallen ist und natürlich auch stärkere Auswirkungen hat, je mehr Erweiterungen installiert sind.
3. Ich bin ja auch selbst Entwickler und es gibt schon genügend Sachen, die sich ständig ändern, was nervig sein kann.
Es wäre in dieser Hinsicht natürlich ein Nachteil.
Man müsste eben mal testen, wie groß der Geschwindigkeitsvorteil ist.

Dann wäre es vielleicht wenigstens vorteilhaft zu sagen, dass $this->text und $this->archive nur bei Bedarf zur Verfügung steht?

Wenn jetzt die meisten Entwickler es so sehen, dass hier für den Großteil der Websites kaum ein Geschwindgkeitsvorteil gegeben wäre, dann akzeptiere ich auch den IST-Zustand

Anfänglich ging es darum, richtig. Aber hab ich eben das Gefühl, dass das Problem rein optischer Natur ist ;-)

Und deine Analyse hat ja gezeigt wo das "Problem" liegt. Nur das hat ja nichts mit dem Template zu tun, zumal hier ja kein weiterer Speicher notwendig ist, da die Daten ja eh bereits durch die Selektion geladen/verarbeitet wurden. Daher ist diese Diskussion was letztendlich im Template zur Verfügung steht so unsinnig. Eine Optimierung kann ja nur direkt im Framework erfolgen, nicht erst im Template....

Und dieser erhöhte Speicherverbrauch wird sicherlich auch nur durch die Generierung der Sitemap erzeugt, richtig? Denn für die Anzeige der News, gibt es offsets, somit werden pro Seite nie mehr als 50? Datensätze überhaupt geladen. Wenn jemand 10.000 Datensätze auf einer Seite anzeigen möchte ist die Performance des CMS das geringste Problem. Ich denke da wird eher der Browser aussteigen.

1. Oh man... Es ist kein optisches Problem wegen der Vielzahl an Variablen... Ich sah darin nur ein eventuelles Performanceproblem.

2. Es gibt auch einen extremen Speicherverbrauch bei den Events.
Hier ist es anders als bei den News. Denn hier kann sich das bei 10.000 Events extrem aufbauschen, da bei wiederholenden jeder einzelne Termin im Array hinzugefügt wird und anschließend sogar noch eine Sortierung stattfindet.
Auf diese Weise ist der SELECT nicht durch ein OFFSET/LIMIT begrenzt.

[the_scrat]

@Spooky Natürlich macht man das so nicht, wie ich das gesagt habe. Aber die Funktion, wie es gemacht wird (derzeit) funktioniert ja nur bedingt ;-)

Und du hattest ja selbst schon den Vorschlag mit den Chunks 2000/5000.
Und eine Sitemap hat sicherlich nicht die Priorität in Echtzeit zur Verfügung zu stehen. Gerade wenn vielleicht mehrere Leute News bearbeiten würde das System ja ständig immer alles verarbeiten.

[the_scrat]

Ich kann mir auch vorstellen, dass es bei anderen CMS genauso gehandhabt wird. Aber Ich dachte mir, dass ich einfach mal nachfrage nachdem mir das schon jahrelang aufgefallen ist und natürlich auch stärkere Auswirkungen hat, je mehr Erweiterungen installiert sind.

Nachfragen ist ja das eine, Behauptungen aufstellen das andere. Und dass eine vielzahl an Erweiterungen nicht gerade performancefreundlich ist sollte klar sein. Da helfen die besten Abfrageoptimierungen nix, wenn irgendwelche Erweiterungen dann alles "versauen".

3. Ich bin ja auch selbst Entwickler und es gibt schon genügend Sachen, die sich ständig ändern, was nervig sein kann.
Es wäre in dieser Hinsicht natürlich ein Nachteil.
Man müsste eben mal testen, wie groß der Geschwindigkeitsvorteil ist.

Na dann hau rein :-) Mach Benchmarktests, optimiere die Models und gib deine Ergebnisse auf Github an die Core-Entwickler weiter, damit wäre dann tatsächlich allen geholfen.

Dann wäre es vielleicht wenigstens vorteilhaft zu sagen, dass $this->text und $this->archive nur bei Bedarf zur Verfügung steht?

Sagen kannst du das ;-) Trotzdem hat es keinen wirklichen Nachteil, dass diese Daten im Template abrufbar sind. Da diese ja eh schon im Speicher sind....

2. Es gibt auch einen extremen Speicherverbrauch bei den Events.
Hier ist es anders als bei den News. Denn hier kann sich das bei 10.000 Events extrem aufbauschen, da bei wiederholenden jeder einzelne Termin im Array hinzugefügt wird und anschließend sogar noch eine Sortierung stattfindet.
Auf diese Weise ist der SELECT nicht durch ein OFFSET/LIMIT begrenzt.

Hier solltest du dir das Detail ansehen. Wie verhalten sich die Events wenn kein Feed generiert werden muss? Natürlich kannst du auch bei wiederholenden Terminen mit Offsets arbeiten, ansonsten würde ja das Contao Backend garnicht mehr funktionieren wenn du in den Bereich Events wechselst. Ein Serientermin ist ja nichts anderes als viele einzelne Termine auf Basis (Referenz) eines einzelnen.