Newsarchiv mit über 10.000 Einträgen sprengt Speicher

Hallo zusammen,
ich stehe gerade vor der Aufgabe eine Webseite von Drupal noch Contao zu überführen und dabei den alten Bestand an News aus SEO-Gründen mit zu übernehmen. Dabei handelt es sich um derzeit rund 10.500 Beiträge die größtenteils nur aus dem Teaser bestehen und insgesamt in der Datenbanktabelle tl_news gerade mal 6,2 MB belegen. An sich also recht überschaubar.
Wenn nun ein neuer Beitrag erfasst werden soll oder ein älterer bearbeitet wird kommt es allerdings immer zu einem Speicherfehler dieser Art:

Code:

---

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted

---

Das sieht mir ganz danach aus als wenn Contao wirklich mehr als 256MB an Arbeitsspeicher haben will nur um die News abzuspeichern. Kann das mit rechten Dingen zugehen? Und wenn ja - wie kann ich das umgehen ohne ein eigenes News-Modul zu programmieren? Die Release 3.3 hatte ich noch nicht getestet da ich für den Kunden die LTS 3.2 einsetzen sollte.
Vielen Dank schon mal im Voraus.
JBN

Ich habe das Problem nun soweit eingegrenzt das bei der Erstellung eines neuen News-Eintrags ein Select ausgeführt wird das alle Artikel aus der tl_news nebst diverser weiterer Daten aus den Tabellen tl_news_archive und tl_user ermittelt - wobei ich noch nicht gefunden habe, wo und warum dieses Statement benötigt wird.
Durch die Ergebnisse in diesem Statement werden aus den rund 6,5MB in der Datenbank-Tabelle tl_news eine Datenmenge von über 150MB wenn man dieses Statement direkt in phpMyAdmin mal ausgeben lässt. Das das in Verbindung mit der Datenhaltung dann die 256MB RAM für die PHP Prozess killt, ist verständlich.
Kann mir jemand mal den Wald vor Augen lichten und mir sagen, wo ich ansetzen sollte um diese Speichernutzung einzugrenzen? Mal abgesehen davon dem Kunden zu sagen das er alte News löschen soll... was aber keine gute Option wäre.

Hier das besagte SQL-Statement:

Code:

---

SELECT tl_news.*, j1.id AS pid__id, j1.tstamp AS pid__tstamp, j1.title AS pid__title, j1.jumpTo AS pid__jumpTo, j1.protected AS pid__protected, j1.groups AS pid__groups, j1.allowComments AS pid__allowComments, j1.notify AS pid__notify, j1.sortOrder AS pid__sortOrder, j1.perPage AS pid__perPage, j1.moderate AS pid__moderate, j1.bbcode AS pid__bbcode, j1.requireLogin AS pid__requireLogin, j1.disableCaptcha AS pid__disableCaptcha, j2.id AS author__id, j2.tstamp AS author__tstamp, j2.username AS author__username, j2.name AS author__name, j2.email AS author__email, j2.google AS author__google, j2.language AS author__language, j2.backendTheme AS author__backendTheme, j2.uploader AS author__uploader, j2.showHelp AS author__showHelp, j2.thumbnails AS author__thumbnails, j2.useRTE AS author__useRTE, j2.useCE AS author__useCE, j2.password AS author__password, j2.pwChange AS author__pwChange, j2.admin AS author__admin, j2.groups AS author__groups, j2.inherit AS author__inherit, j2.modules AS author__modules, j2.themes AS author__themes, j2.pagemounts AS author__pagemounts, j2.alpty AS author__alpty, j2.filemounts AS author__filemounts, j2.fop AS author__fop, j2.forms AS author__forms, j2.formp AS author__formp, j2.disable AS author__disable, j2.start AS author__start, j2.stop AS author__stop, j2.session AS author__session, j2.dateAdded AS author__dateAdded, j2.lastLogin AS author__lastLogin, j2.currentLogin AS author__currentLogin, j2.loginCount AS author__loginCount, j2.locked AS author__locked, j2.calendars AS author__calendars, j2.calendarp AS author__calendarp, j2.calendarfeeds AS author__calendarfeeds, j2.calendarfeedp AS author__calendarfeedp, j2.faqs AS author__faqs, j2.faqp AS author__faqp, j2.news AS author__news, j2.newp AS author__newp, j2.newsfeeds AS author__newsfeeds, j2.newsfeedp AS author__newsfeedp, j2.newsletters AS author__newsletters, j2.newsletterp AS author__newsletterp FROM tl_news LEFT JOIN tl_news_archive j1 ON tl_news.pid=j1.id LEFT JOIN tl_user j2 ON tl_news.author=j2.id WHERE tl_news.pid='1' AND tl_news.source='default' AND (tl_news.start='' OR tl_news.start<1408466706) AND (tl_news.stop='' OR tl_news.stop>1408466706) AND tl_news.published=1 ORDER BY tl_news.date DESC

---

Vielen Dank noch mal im Voraus in der Hoffnung auf eine kleine Machete (zum Wald auslichten).
Thanx.
JBN

Vielleicht ältere Daten in separate New-Archive ablegen (sind ja nach gewisser Zeit keine News mehr ... vielmehr Oldies) z.Bsp. nach Jahren sortiert. Dann wird doch die Datenmenge doch auch erheblich kleiner.

Bevor man hier einen Workaround macht sollte man aber auf jeden Fall herausfinden, warum es zu diesem SELECT kommt - damit man das im Core ggf. verbessern kann.

Ich habe zwar von MySQL etc. keine wirkliche Ahnung, aber beim Durchlesen kam mir Folgendes in den Sinn …

Wenn das erst beim Speichern der News auftritt, würde ich es für möglich halten, dass es an der Prüfung des Alias liegen könnte. Contao durchläuft dabei wahrscheinlich alle Datenbankeinträge der News um einen ein doppeltes Alias auszuschließen. Damit könnte ich mir nach meiner Vorstellung den massiven Speicherbedarf vage erklären …

Zitat:

---

Zitat von Dexter Paris

Wenn das erst beim Speichern der News auftritt, würde ich es für möglich halten, dass es an der Prüfung des Alias liegen könnte. Contao durchläuft dabei wahrscheinlich alle Datenbankeinträge der News um einen ein doppeltes Alias auszuschließen. Damit könnte ich mir nach meiner Vorstellung den massiven Speicherbedarf vage erklären …

---

Nein, die Funktion zum generieren des Alias macht nur ein einfachen SELECT:

PHP-Code:

---

    /**
     * Auto-generate the news alias if it has not been set yet
     * @param mixed
     * @param \DataContainer
     * @return string
     * @throws \Exception
     */
    public function generateAlias($varValue, DataContainer $dc)
    {
        $autoAlias = false;

        // Generate alias if there is none
        if ($varValue == '')
        {
            $autoAlias = true;
            $varValue = standardize(String::restoreBasicEntities($dc->activeRecord->headline));
        }

        $objAlias = $this->Database->prepare("SELECT id FROM tl_news WHERE alias=?")
                                   ->execute($varValue);

        // Check whether the news alias exists
        if ($objAlias->numRows > 1 && !$autoAlias)
        {
            throw new Exception(sprintf($GLOBALS['TL_LANG']['ERR']['aliasExists'], $varValue));
        }

        // Add ID to alias
        if ($objAlias->numRows && $autoAlias)
        {
            $varValue .= '-' . $dc->id;
        }

        return $varValue;
    } 


---

Hi,

um den Fehler mal weiter einzuschränken: Ich hab nicht gelesen, dass es erst beim Speichern auftritt, sondern wohl beim Erstellen. Somit beim Laden einer neuen News, oder?

Demnach kommen da nicht so viele Optionen in Frage

PHP-Code:

---

'onload_callback' => array
(
       array('tl_news_archive', 'checkPermission'),
       array('tl_news_archive', 'generateFeed')
), 


---

checkPermission macht zwar ein paar kleine wenige Abfrage, aber nichts, was den Speicher so in die Höhe treiben könnte.
Bleibt noch generateFeed. Das geschieht sowohl in der tl_news als auch im tl_news_archiv. Im tl_news wird nicht so arg viel passieren denk ich mal, aber in der tl_news_archive könnte es die Probleme geben. Auch vom SQL Statement. Warum soll sonst nach published=1 abgefragt werden inkl. start und stop-Zeit.

@JBN probier doch mal bitte folgendes (nur ein Test um die Sache zu verifizieren).

Öffne die Datei /system/modules/news/dca/tl_news_archive.php Zeile 409 (zumindest bei mir Contao 3.3.irgendwas). Oder such einfach nach generateFeed()
Mach aus

PHP-Code:

---

public function generateFeed()
{
       $session = $this->Session->get('news_feed_updater'); 


---

das hier:

PHP-Code:

---

public function generateFeed()
{
  return;
       $session = $this->Session->get('news_feed_updater'); 


---

Wie gesagt, nur zum testen. Bin gespannt ob es der Feed ist.....


Edit: ich glaub garnicht, dass es der Feed ist, sondern die Methode die danach kommt und zwar generateSitemap. Aber jetzt erstmal testen ob das return hilft.

Zitat:

---

Zitat von the_scrat

Wie gesagt, nur zum testen. Bin gespannt ob es der Feed ist.....

Edit: ich glaub garnicht, dass es der Feed ist, sondern die Methode die danach kommt und zwar generateSitemap. Aber jetzt erstmal testen ob das return hilft.

---

Super. Danke... es ist die Generierung der Sitemap über den Automator.
Wenn ich die Sitemap in der Einstellung deaktiviere braucht Contao nur rund 6MB an Speicher beim speichern eines neuen Beitrags - wenn ich die Sitemap wieder aktiviere sind es in meine Fall über 280 MB die Contao dann braucht.

Ich werde mir die Sitemap-Funktion mal ansehen und schauen in wie weit man dafür eine Optimierung durchführen kann - ich kann mir nicht vorstellen das man wirklich ein SELECT * auf die ganzen Tabellen benötigt um die Sitemap zu erstellen da die ja eigentlich nur aus den URLs besteht. Aber ich denke das ist erst einmal ein Workaround die Sitemap zu deaktivieren mit dem ich für den Projektstart leben kann.

Vielen Dank für die super Idee.
Schöne grüße aus der Hauptstadt.
JBN

Hi,

vorallem frage ich mich, welchen Sinn es macht die Sitemap beim ERSTELLEN einer neuen Nachricht zu generieren. Logisch betrachtet würde eine Generierung der Sitemap doch erst nach dem Speichern wirklich Sinn ergeben, oder nicht?
Edit: Das muss ich mir selbst wiedersprechen: der load_callback wird ja immer ausgeführt. Also vor dem Erstellen als auch nach dem Speichern. Macht trotzdem keinen Sinn, den Mist 2x laufen zu lassen. Einmal nach dem Speichern, fertig :-)

Naja, in jedem Fall, Problem behoben.

Solltest du ein Optimierungspotiential finden, eröffne am besten ein Ticket auf Github, damit das fest in den Core übernommen wird.

Ich denke eigentlich das die Erstellung der Sitemap eher etwas für den Cron ist - oder zumindest optional nur per Cron ggf. sogar nur einmal am Tag generiert werden sollte. Na ich werde mir demnächst das mal ansehen wenn ich mit dem aktuellen Projekt durch bin... das deaktivieren der Sitemaps hat ja jedenfalls das arbeiten mit Contao wieder ermöglicht.

Hm, der hohe Speicherverbrauch tritt im Endeffekt wegen der Collection bzw. der Models (NewsModel) auf. Genauer gesagt hier: https://github.com/contao/core/blob/...ction.php#L155
Ob jetzt allerdings das Erzeugen von 10000 NewsModel Objekte alleine schon den riesigen Speicherverbrauch verursacht oder etwas im Model Konstruktor dafür verantwortlich ist (bzw. den Speicherverbrauch verschlimmert) habe ich allerdings noch nicht näher angesehen.

Analyse - Ausgangspunkt sind 10000 tl_news Einträge.

• Baseline: 5 MiB
• (News)Model Objekterzeugung: + 43.75 MiB
• Laden des DCA Objektes im Model Konstruktor: + 0.5 MiB
• Laden der Relations: + 17 MiB
• Erzeugen der Related Models: + 118 MiB
• Registrieren in der Model Registry: + 29.25 MiB

(Gesamt: 213.5 MiB)

Die Relation haut hier anscheinend mächtig rein. Und in diesem Fall ist die Relation einfach das dazugehörige tl_news_archive Objekt. Es gibt ja pro tl_news Eintrag ja eigentlich nur ein dazugehöriges Archiv - wenn ich da jetzt nicht ganz falsch liege sieht das ganze eigentlich so aus, wie wenn da für 10000 tl_news Einträge auch 10000 mal ein tl_news_archive Objekt existiert.

Dann war ja meine Idee, des Aufteilens des News-Archives als Workaround für die LTS Version 3.2, gar nicht so abwegig ;)

@Spooky, danke für die Analyse welche hilft Contao zu verbessern!

Zitat:

---

Zitat von ciaobello

Dann war ja meine Idee, des Aufteilens des News-Archives als Workaround für die LTS Version 3.2, gar nicht so abwegig ;)

---

Ja naja, wenn man aber trotzdem weiterhin alle News-Artikel im Frontend aufrufbar haben will und eine Sitemap generieren lassen will, dann hat man das Problem nur dann nicht, wenn man wirklich alle News-Beiträge immer auf mehrere Archive aufteilt, immer zu je, sagen wir, 5000 Stück.


Eine generelle Lösung für ein derartiges Speicherproblem wäre hier vielleicht so etwas wie eine "ChunkedCollection", oder etwas in der Art. Grob umrissen:

Statt

PHP-Code:

---

// Get the items
$objArticle = \NewsModel::findPublishedDefaultByPid($objArchive->id);

if ($objArticle !== null)
{
    while ($objArticle->next())
    {
        // ...
    }
} 


---

würde man dann so etwas wie:

PHP-Code:

---

// Get a chunked collection to save memory
// findPublishedDefaultByPid now returns a ChunkedCollection instead of a regular Collection
// (through the second boolean parameter for instance)
$objChunkedCollection = \NewsModel::findPublishedDefaultByPid($objArchive->id, true); 

while ($objChunkedCollection->next())
{
    // Get the items
    $objArticle = $objChunkedCollection->getItems();

    if ($objArticle !== null)
    {
        while ($objArticle->next())
        {
            // ...
        }
    }    
} 


---

ausführen. Die ChunkedCollection würde dann die Items immer nur in fixen Chunks erzeugen, zu je 1000 bis 5000 Stück bspw.

Leider hatte ich noch keine Zeit mich mit der Analyse zu beschäftigen - aber ich kann mir derzeit keinen Grund vorstellen, warum man wirklich alle Newsmeldungen mit dem ganzen Overhead im Speicher halten muss. Die Sitemap beinhaltet doch nur die URLs - wozu müssen da Informationen über den Autor und die Teasertexte aus den News mit eingeladen werden? Und wenn sie für eventuelle Entscheidungen, ob die News "published" ist oder nicht, benötigt werden, dann sollte das entleeren des Speichers zwischendurch ermöglichen das eben nicht alle Daten im Speicher bleiben. Aber vielleicht denke ich auch gerade "zu einfach" - ich werde es aber noch herausfinden.
Vielen Dank jedenfalls an alle für die Tipps die mir den Start des Projektes erst einmal wieder ermöglicht haben. Ich hatte schon alle Felle davon schwimmen sehen...
Ich wünsche ein schönes Wochenende.
JBN

Zitat:

---

Zitat von JBN

Leider hatte ich noch keine Zeit mich mit der Analyse zu beschäftigen - aber ich kann mir derzeit keinen Grund vorstellen, warum man wirklich alle Newsmeldungen mit dem ganzen Overhead im Speicher halten muss. Die Sitemap beinhaltet doch nur die URLs - wozu müssen da Informationen über den Autor und die Teasertexte aus den News mit eingeladen werden? Und wenn sie für eventuelle Entscheidungen, ob die News "published" ist oder nicht, benötigt werden, dann sollte das entleeren des Speichers zwischendurch ermöglichen das eben nicht alle Daten im Speicher bleiben. Aber vielleicht denke ich auch gerade "zu einfach" - ich werde es aber noch herausfinden.
Vielen Dank jedenfalls an alle für die Tipps die mir den Start des Projektes erst einmal wieder ermöglicht haben. Ich hatte schon alle Felle davon schwimmen sehen...
Ich wünsche ein schönes Wochenende.
JBN

---

Die Newsmeldungen werden nicht im Speicher gehalten. Sie werden einfach alle geladen (als Models), damit die URLs erzeugt werden können. Nach dem Erzeugen der URLs werden die Objekte nicht mehr gebraucht und der Speicher wird von PHP natürlich auch freigegeben.

Zitat:

---

Zitat von Spooky

Die Newsmeldungen werden nicht im Speicher gehalten. Sie werden einfach alle geladen (als Models), damit die URLs erzeugt werden können. Nach dem Erzeugen der URLs werden die Objekte nicht mehr gebraucht und der Speicher wird von PHP natürlich auch freigegeben.

---

Das ist schon klar das die nicht dauerhaft im Speicher bleiben - aber während der Generierung der Sitemap werden halt alle Daten in einem Rutsch wohl in den Speicher geladen und dann die Sitemap erstellt... aber wie schon gesagt - warum alle Details der News (im übrigen auch der tl_pages) eingeladen werden und kein selektiveres SQL-Statement verwendet wird um eben den Speicherbedarf insgesamt geringer zu halten ist die Frage die ich mir dann ansehen werden.
Für "kleine" Installationen mit nur wenigen Seiten und News klappt das sicherlich gut - wenn die Installation allerding eben viele tausend Datensätze beinhaltet scheint das eben ein Nadelöhr zu sein.

Zitat:

---

Zitat von JBN

Das ist schon klar das die nicht dauerhaft im Speicher bleiben - aber während der Generierung der Sitemap werden halt alle Daten in einem Rutsch wohl in den Speicher geladen und dann die Sitemap erstellt... aber wie schon gesagt - warum alle Details der News (im übrigen auch der tl_pages) eingeladen werden und kein selektiveres SQL-Statement verwendet wird um eben den Speicherbedarf insgesamt geringer zu halten ist die Frage die ich mir dann ansehen werden.

---

Es würde (in deinem Fall) schon reichen wenn man einfach ein SQL Statement macht (wo auch ruhig alles geladen werden kann) und die News nicht über eine Collection lädt. Da würde es dann erst bei 10 oder gar 100 mal so viel Datensätzen zum Problem werden.

Siehe dazu auch https://github.com/contao/core-bundle/issues/333.

Das tritt bei Events ja auch auf.
Und irgendwie war es bei Contao schon immer so, dass etliche Daten sinnlos geladen werden.
Allein wenn ich mir ansehe wieviele ungenutzte Daten angezeigt werden wenn man in ein Template $this->showTemplateVars(); einträgt.

Leo: Alle die in dem Github Thread posten, sprechen Deutsch, aber ihr schreibt trotzdem auf Englisch. Versteh das einer :D

Zitat:

---

Zitat von Stranger

Das tritt bei Events ja auch auf.
Und irgendwie war es bei Contao schon immer so, dass etliche Daten sinnlos geladen werden.
Allein wenn ich mir ansehe wieviele ungenutzte Daten angezeigt werden wenn man in ein Template $this->showTemplateVars(); einträgt.

---

Hmm für den einen sinnlos, für den anderen Nützlich um die Ausgabe anzupassen oder eben doch mehr auszugeben usw.

Zitat:

---

Zitat von Stranger

Leo: Alle die in dem Github Thread posten, sprechen Deutsch, aber ihr schreibt trotzdem auf Englisch. Versteh das einer :D

---

1. können dann auch nicht deutschsprachler mitlesen und sich informieren
2. können nicht deutschsprachler auch mitreden

Ist einfach sinnvoll in einer großen Community, wo verschiedene sprachen zusammentreffen um möglichst keinen auszuschließen.

Viele Grüße

Zitat:

---

Zitat von Stranger

Das tritt bei Events ja auch auf.

---

Macht keinen Unterschied, es ist/war ein Problem mit den Models generell.


Es gibt hierfür nun einen Fix: https://github.com/contao/core-bundl...fe01047815d00f (die gefixte Model.php kann auch in Contao 3.5 eingesetzt werden - oder man übernimmt nur Zeile 139 bis 177 aus der neuen Model.php). Siehe dazu auch https://github.com/contao/core-bundl...ment-133805577 & ff.
Der Fix wird in Contao 4.0.3 und ich denke auch in Contao 3.5 integriert (wenn er getestet wurde).

Zitat:

---

Zitat von MacKP

Hmm für den einen sinnlos, für den anderen Nützlich um die Ausgabe anzupassen oder eben doch mehr auszugeben usw.

---

Dahinter steckt doch doch ein SELECT * FROM... oder etwa nicht?
Und ich denke da besteht große Einigkeit, dass man so etwas nicht tun sollte.

Zitat:

---

Zitat von Stranger

Dahinter steckt doch doch ein SELECT * FROM... oder etwa nicht?
Und ich denke da besteht große Einigkeit, dass man so etwas nicht tun sollte.

---

Welche sinnlosen Daten im speziellen meinst du überhaupt?

Schreib doch mal <?php echo $this->showTemplateVars(); ?> bspw. in das Template "news_latest".
Bestimmt 90% der Angaben davon sind in den allermeisten Fällen sinnlos, weil sie nicht gebraucht werden.

Nur weil DU sie nicht brauchst, heißt es nicht, dass sie sinnlos sind. Ansonsten schreib dir halt deine eigene Model und Templateklasse, dann entscheidest du, was selektiert und ans Template weitergegeben wird.
Ich halte die Informationen sehr wohl für notwendig. Und es gibt auch offsets, bedeutet, dass nur max. 10?20? Zeilen überhaupt geladen werden...... wo ist das Problem? Das 10.000 Einträgeproblem ist ja nur in Verbindung mit der Erstellung einer Sitemap verbunden, weil hier nunmal alle Einträge durchlaufen werden müssen. Also wenn es optimierungsbedarf gibt, dann, dass man hier evtl. die Generierung (z.B. per Cron) in mehreren Schritten und vielleicht nicht direkt mit dem Speichern gemeinsam erledigt.

Im normalen Webseitenbetrieb sollte die vollständige Weitergabe einer row an das Template nicht weiter ins Gewicht fallen!

Zitat:

---

Zitat von Stranger

Bestimmt 90% der Angaben davon sind in den allermeisten Fällen sinnlos, weil sie nicht gebraucht werden.

---

Ich wiederhole meine Frage: welche Variablen sind für dich sinnlos? Wenn du diese Frage beantwortest, dann können wir dir sagen ob diese Variable sinnlos ist oder nicht.

spooky hab dir eine PN geschickt mit einem Link.

the_scrat:
Was ist das denn für eine merkwürdige Argumentation. Es geht doch überhaupt nicht um mich?
Ich werde garantiert nicht dazu übergehen mir für jedes Contao-Modul und den Core Anpassungen vornehmen...

Es geht um die meisten User, die die meisten ihrer Templates eben nicht anpassen!

Wenn wir jetzt einen User haben, der das Template news_simple einsetzt...

Ich schreibe in das Template:
<?php echo $this->showTemplateVars(); ?>


Welche Angaben brauche ich hier?
$this->archive->id
$this->class
$this->date
$this->datetime
$this->linkHeadline

Demnach sind alle anderen Variablen überflüssig.

Am krassesten ist die "Sinnlosigkeit" bei $this->archive und $this->text - Beides extrem verschachelt und mit eigenen Variablen, bis zu 100 oder so... ich kann es kaum zählen (auch abhängig von Art und Anzahl von installierten Erweiterungen)

Sorry, aber das, was du willst, ist garnicht machbar.

Und doch, es geht um dich, daher die Argumentation, weil Du ja das möchtest und den Sinn der Variablen in Frage stellst.
Wenn ein User in der Lage ist $this->showTemplateVars(); in ein Template zu schreiben, dann sollte man auch erwarten können, dass er mit dem Resultat (egal wie groß es sein mag) umgehen kann.

Und nochmal, wer entscheidet, ob etwas überflüssig ist, oder nicht? Wer sagt, dass man im Template nicht eine Abfrage macht und genau $this->text oder $this->archive benötigt um dort Werte zu vergleichen?!

Zitat:

---

Zitat von Stranger

Welche Angaben brauche ich hier?
$this->archive->id
$this->class
$this->date
$this->datetime
$this->linkHeadline

Demnach sind alle anderen Variablen überflüssig.

---

Ja, du brauchst diese Variablen hier, bzw. die anderen nicht. Wenn aber jemand egal welches Template ändern will und beliebige Informationen des Events einsetzen will, dann müssen auch einfach all diese Daten im Idealfall vorhanden sein.

Zitat:

---

Zitat von Stranger

Am krassesten ist die "Sinnlosigkeit" bei $this->archive und $this->text - Beides extrem verschachelt und mit eigenen Variablen, bis zu 100 oder so... ich kann es kaum zählen (auch abhängig von Art und Anzahl von installierten Erweiterungen)

---

$this->archive ist eine Objekt Referenz und verbraucht nur ein paar byte Speicher (und die Referenz ist mit dem hier angesprochenen Fix auch tatsächlich nur mehr eine Referenz auf ein Objekt) und $this->text ist seit Contao 3.5 ebenfalls eine Referenz auf eine Anonymous Function - dessen Ausgabe sieht einfach so aus. Diese Anonymous Function lädt den eigentlichen Textinhalt (also die Inhaltselemente des Events) erst On Demand nach. Das verringert die Speicherauslastung und Prozesszeit für Eventlist Module dramatisch.

Zitat:

---

Zitat von the_scrat

Sorry, aber das, was du willst, ist garnicht machbar.

Und doch, es geht um dich, daher die Argumentation, weil Du ja das möchtest und den Sinn der Variablen in Frage stellst.
Wenn ein User in der Lage ist $this->showTemplateVars(); in ein Template zu schreiben, dann sollte man auch erwarten können, dass er mit dem Resultat (egal wie groß es sein mag) umgehen kann.

Und nochmal, wer entscheidet, ob etwas überflüssig ist, oder nicht? Wer sagt, dass man im Template nicht eine Abfrage macht und genau $this->text oder $this->archive benötigt um dort Werte zu vergleichen?!

---

Ich möchte es nicht primär für mich, sondern es soll einen Vorteil für alle bringen.
Im Endeffekt ist es ein SELECT * FROM oder etwa nicht???
Bei vielen Website-Aufrufen ist eine Contao-Website eben dann viel unperformanter als Websites ohne SELECT * FROM. Auch wenn es nur 20 oder 30 Einträge sind. Trotzdem kann sich das bei großen Websites extrem summieren...

Zitat:

---

Zitat von Spooky

Ja, du brauchst diese Variablen hier, bzw. die anderen nicht. Wenn aber jemand egal welches Template ändern will und beliebige Informationen des Events einsetzen will, dann müssen auch einfach all diese Daten im Idealfall vorhanden sein.

---

Das ist mir schon klar, nur betrifft das ja nur die Leute, die dieses Template anpassen wollen.
Was wäre denn, wenn man folgendes machen würde...

1. In jeder Erweiterung wird vorher unterschieden für welches Template welche Variablen bereitgestellt werden.
2. Wenn jemand in einem Template weitere Variablen benötigt, muss er das festlegen. Das könnte man dann evtl. im Backend unter Templates darstellen - über der Textarea "Quelltexteditor"

Sowas könnte man machen, bringt aber für die meisten nichts und für high volume Fälle muss man sich sowieso irgendwann eigene Lösungen überlegen.

Zitat:

---

Zitat von Stranger

Ich möchte es nicht primär für mich, sondern es soll einen Vorteil für alle bringen.

---

Das liest sich aber anders :-)

Zitat:

---

Zitat von Stranger

Im Endeffekt ist es ein SELECT * FROM oder etwa nicht???

---

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).

Zitat:

---

Zitat von Stranger

Bei vielen Website-Aufrufen ist eine Contao-Website eben dann viel unperformanter als Websites ohne SELECT * FROM. Auch wenn es nur 20 oder 30 Einträge sind. Trotzdem kann sich das bei großen Websites extrem summieren...

---

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

Zitat:

---

Zitat von Stranger

Das ist mir schon klar, nur betrifft das ja nur die Leute, die dieses Template anpassen wollen.
Was wäre denn, wenn man folgendes machen würde...

1. In jeder Erweiterung wird vorher unterschieden für welches Template welche Variablen bereitgestellt werden.
2. Wenn jemand in einem Template weitere Variablen benötigt, muss er das festlegen. Das könnte man dann evtl. im Backend unter Templates darstellen - über der Textarea "Quelltexteditor"

---

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?

Zitat:

---

Zitat von the_scrat

Und das "nur" weil dir die Ausgabe von $this->showTemplateVars() nicht gefällt?

---

Naja, ihm geht es ja um den Speicherverbrauch, bzw. darum geht es ja hier in diesem Thread.

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.

Zitat:

---

Zitat von the_scrat

Und dieser erhöhte Speicherverbrauch wird sicherlich auch nur durch die Generierung der Sitemap erzeugt, richtig?

---

Im Prinzip ja, aber diese wird beim ändern von News/Events bzw. wenn ein neuer Eintrag gemacht wird erzeugt und dadurch kann man auch nichts neues mehr anlegen oder irgendetwas ändern.

Richtig, eine Optimierung des Models wurde ja bereits gemacht. Und in der Praxis kommt dieser hohe Speicherbedarf auch nur in einer einzigen Situation vor, nämlich dem Generieren der Sitemap, egal ob Event oder News. Wenn man nun diesen Prozess auslagert (per Cron etc.) gäbe es sonst keine Probleme mehr, da ja Contao von sich aus schon für die Anzeige mit einem Offset arbeitet, ebenfalls im Frontend werden niemals 10.000 Datensätze selektiert. Das Problem ist nach wie vor die Sitemap. Und hier könnte man statt auf das Model spezifische DB Abfrage mit den tatsächlich benötigten Feldern machen (hier macht das Sinn, im Template nicht), denn was in der Sitemap steht ist ja vorgegeben.

Zitat:

---

Zitat von the_scrat

Wenn man nun diesen Prozess auslagert (per Cron etc.) gäbe es sonst keine Probleme mehr

---

Naja doch, es wird halt keine Sitemap mehr generiert, wenn dabei der Speicher ausgeht ;)

Deswegen schreib ich ja, dass man den Prozess auslagern soll z.B. als Cronjob und vielleicht einem Offset.
Cronjob pro Minute, Einträge zu bearbeiten..... 2000? Dann dauert die Erstellung einer Sitemap halt mal 5 Min. aber das System wird zur Laufzeit nicht wirklich belastet weil ja der onload_callback wegfällt.
So meinte ich das :-)

Zitat:

---

Zitat von the_scrat

Deswegen schreib ich ja, dass man den Prozess auslagern soll z.B. als Cronjob und vielleicht einem Offset.
Cronjob pro Minute, Einträge zu bearbeiten..... 2000? Dann dauert die Erstellung einer Sitemap halt mal 5 Min. aber das System wird zur Laufzeit nicht wirklich belastet weil ja der onload_callback wegfällt.
So meinte ich das :-)

---

Nein, das ändert ja nichts. Wenn der Speicher ausgeht, dann bricht das Script ab. Egal wie du es aufgerufen hast.

Ö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.

Zitat:

---

Zitat von the_scrat

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

Zitat:

---

Zitat von the_scrat

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 ;)

Zitat:

---

Zitat von the_scrat

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... :D 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.

@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.

Zitat:

---

Zitat von Stranger

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".

Zitat:

---

Zitat von Stranger

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.

Zitat:

---

Zitat von Stranger

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

Zitat:

---

Zitat von Stranger

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.