Memory Size Exhausted: Row Style -> Node oder Fields
Eingetragen von jan.s (44)am 13.01.2010 - 16:17 Uhr in
Hallo zusammen,
ich habe einen eigenen Inhaltstyp erstellt, welcher ca. 90 Felder enthält (meiste Strings mit ca. 10-20 Zeichen Länge). Dann habe ich eine View, welche ca. 200 Nodes selektiert, weiterhin ist jede Node über eine Node Reference mit zwei weiteren Nodes anderen Typs verknüpft. Es werden also ca. 600 Nodes geladen.
Wenn ich die View (Row Style : Node) aufrufe, erhalte ich einen Memory Error (bei ca. 17 Sekunden und 79,99 MB verbrauchtem Speicher). Ich habe etwas herumexperimentiert mit "Items to display", die Grenze liegt ca. bei 35 angezeigten Nodes. Dann klappt noch alles, aber die Seitenerstellung dauert halt um die 15 Sekunden.
Wenn ich den Row Style der View auf Fields setze, dann funktioniert alles. Die Menge der angezeigten Nodes kann ich nicht reduzieren, ich brauche jedoch nicht alle Felder, sondern jeweils nur drei. Daher kann ich auch den Row Style Fields verwenden und baue mir dann halt ein passendes Template.
Meine Fragen:
1. Ist das Problem normal, dass es bei der Menge an Daten so lange dauert oder scheint es noch ein anderes Problem zu geben?
2. Kann man erreichen, dass die Nodes (wie mit node_load() möglich) nicht gecacht werden?
Viele Grüße
Jan
- Anmelden oder Registrieren um Kommentare zu schreiben
Da ich gerade vor ein paar
am 13.01.2010 - 17:22 Uhr
Da ich gerade vor ein paar Tagen auch ein solches Problem hatte mal meine Erfahrung dazu:
Also: es scheint SEHR empfehlenswert bei Views mittels fields nur die Felder auszuwählen die man für die jeweilige View auch wirklich benötigt.
Mir scheint es so zu sein, dass ein node_load() nicht nur die Daten des Nodes läd (das war das was ich erwartet hatte) sondern auch 'mal eben' alle Nodes 'rendert' sprich die jeweilige Seite (oder zumindest große Teile davon) als Code erzeugt. Das verbraucht natürlich u.U. wahnsinnig Arbeitsspeicher, und produziert zu dem auch noch reichlich (womöglich unnötige) Datenbankabfragen.
Daher habe ich nun meine Views (die zum teil noch mittels Panels zusammen auf eine Seite gepackt wurden) mit fields aufzubauen und siehe da, der Speicherverbrauch ging deutlich runter, die Seitenbauzeiten normalisierten sich.
zu deinem 2. was meinst du mit 'nicht gecached'? Das dir nur die Daten des Nodes geliefert werden, aber die Seiten nicht erzeugt werden?
Wenn ja, DAS ist etwas, was mich auch interessieren würde.
jan.s schrieb 1. Ist das
am 13.01.2010 - 17:40 Uhr
1. Ist das Problem normal, dass es bei der Menge an Daten so lange dauert oder scheint es noch ein anderes Problem zu geben?
2. Kann man erreichen, dass die Nodes (wie mit node_load() möglich) nicht gecacht werden?
zu 1.
Das kann man nicht allgemeingültig beantworten, weil deine Struktur nicht genua bekannt ist und wir nicht wissen wie ausgelastet der Server ist, welche Einstellungen er fährt, etc.
zu 2.
Node_load() cacht mittels eines statischen Arrays. D.h. lediglich innerhalb eines Skriptlaufs (Aufruf einer Seite) wird das Laden desselben Nodes über den Cache bedient (wenn nicht zwischenzeitlich irgendwo geflusht wurde). In der Zeit wo ein einzelner View lädt, sollte sich ein und derselbe Node nicht verändern - normal sollte er auch nicht mehrfach in einem View angezeigt werden.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Methos schrieb Mir scheint
am 13.01.2010 - 17:45 Uhr
Mir scheint es so zu sein, dass ein node_load() nicht nur die Daten des Nodes läd (das war das was ich erwartet hatte) sondern auch 'mal eben' alle Nodes 'rendert' sprich die jeweilige Seite (oder zumindest große Teile davon) als Code erzeugt. Das verbraucht natürlich u.U. wahnsinnig Arbeitsspeicher, und produziert zu dem auch noch reichlich (womöglich unnötige) Datenbankabfragen.
Dem ist nicht so: http://api.drupal.org/api/function/node_load/6
Denn fürs Rendern ist node_view() zuständig. Aber natürlich muss ein node_load() auch alle hook_nodeapi()-Hooks aller Module durchgehen, um ihnen die Möglichkeit zu geben spezifische Daten an den Node ranzuhängen, wie es eben auch CCK macht.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Methos schrieb zu deinem 2.
am 13.01.2010 - 17:56 Uhr
zu deinem 2. was meinst du mit 'nicht gecached'? Das dir nur die Daten des Nodes geliefert werden, aber die Seiten nicht erzeugt werden?
Wenn ja, DAS ist etwas, was mich auch interessieren würde.
Ja, genau, zum Beispiel. Außerdem gibt es doch bei node_load() mit dem dritten Parameter die Möglichkeit, die Nodes nicht zu cachen.
Nehmen wir mal an, ich lasse mir in der View nur das Field nid ausgeben und damit mache ich dann ein node_load($row->nid) im Template um auf die Node zugreifen zu können. Würde ich das gleiche Problem bekommen und das Script abbrechen? Oder würde hier irgendetwas nicht geladen werden, was die View jedoch geladen hätte? Wenn ja, hätte ich hier Erfolg, wenn der dritte Parameter das Cachen verbietet?
Ich denke trotzdem würde ich in diesem Fall hier nur noch mit den Fields arbeiten, da ich wirklich nur wenige Felder brauche.
Die Nodes werden so oder so
am 13.01.2010 - 18:01 Uhr
Die Nodes werden so oder so geladen. Dabei kommen sie entweder aus dem static array(), oder aber, wenn sie nicht drin sind, wandern sie da rein. Wie du es drehst und wendest kommt dabei derselbe Platzbedarf bei heraus.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Alexander Langer
am 13.01.2010 - 18:20 Uhr
Mir scheint es so zu sein, dass ein node_load() nicht nur die Daten des Nodes läd (das war das was ich erwartet hatte) sondern auch 'mal eben' alle Nodes 'rendert' sprich die jeweilige Seite (oder zumindest große Teile davon) als Code erzeugt. Das verbraucht natürlich u.U. wahnsinnig Arbeitsspeicher, und produziert zu dem auch noch reichlich (womöglich unnötige) Datenbankabfragen.
Dem ist nicht so: http://api.drupal.org/api/function/node_load/6
Denn fürs Rendern ist node_view() zuständig. Aber natürlich muss ein node_load() auch alle hook_nodeapi()-Hooks aller Module durchgehen, um ihnen die Möglichkeit zu geben spezifische Daten an den Node ranzuhängen, wie es eben auch CCK macht.
hm, das deckt sich irgendwie nicht mit dem Effekt, den ich beobachtet hab.
Ich habe einen Inhaltstypen, der in seinem Template einen Block einbindet (Werbebanner, seperater Inhaltstyp).
Lade ich (bei eingeschaltetem Devel-Modul) mit node_load in einem View-Template mit node_load() meine Nodes, habe ich massig Datenbankabrufe, die eben diese Werbebanner abrufen. Setze ich das ganze mit fields um, sind diese aufrufe (und einiges anderes, verständlicher weise) verschwunden. Aus diesem Effekt habe ich geschlossen, dass node_load() da irgendwas macht was wohl reichlich unnötig ist. (Die Werbebanner sind NICHT mit einer node-referenz oder ähnliches mit dem Node verknüpft).
Vll. kann diesen Effekt ja mal jemand erklären!?
Nichts desto trotz werde ich bei der Nutzung von fields bleiben, sofern ich nur wenige Bestandteile meines Nodes benötige, das es (zumindest im aktuellen Projekt) deutlich performanter ist.
Views fragt, je nachem was
am 13.01.2010 - 18:27 Uhr
Views fragt, je nachem was man eingestellt hat, eben nur die unbedingt nötigen Daten aus der Datenbank ab, während node_load() ganz korrekt alle Daten des Nodes lädt.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
naja .. die werbebanner sind
am 14.01.2010 - 17:44 Uhr
naja .. die werbebanner sind aber nur über das template für den Nodetype mit dem node 'verbunden'.
Es wird im Template ein Block ausgegeben, aber es gibt keine Info welcher Node zu welchem Banner gehört oder so etwas.
Es ist einfach nur ein banner mit einem Term verbunden der Ihm sagt dass er eben auf der Node-Seite angezeigt werden soll.
Deswegen erschließt sich mir eben überhaupt nicht, warum die werbebanner bei einem node_load() auftauchen.
Aber was solls. mit der Verwendung von fields isses irgendwie eh besser geworden.. ist also mehr theoretische Neugier.