Author Topic: Leere Seiten bei größeren Datenmengen?  (Read 592 times)

Offline suedstaedter

  • Posts: 35
  • Gender: Male
Leere Seiten bei größeren Datenmengen?
« on: April 18, 2017, 09:40:13 PM »
Hallo,
ich habe Probleme bei größeren Datenmengen. Da kommen auf einmal absolut "leere Seiten". Kleinere Datenmengen werden offenbar problemlos von WebsiteBaker angezeigt. Wenn ich das Skript extern teste (also ohne WebsiteBaker), wird alles korrekt angezeigt. Welche Funktion innerhalb von WebsiteBaker könnte hier die Schwierigkeiten auslösen? Und wie kann man darauf Einfluss nehmen?
Ich nutze noch Version 2.8.3 SP7.
LG suedstaedter
Geduld zu haben ist besser, als ein Held zu sein...
(Die Bibel - Sprüche 16,32a)

Offline suedstaedter

  • Posts: 35
  • Gender: Male
Re: Leere Seiten bei größeren Datenmengen?
« Reply #1 on: April 18, 2017, 09:57:06 PM »
OK, beim Lesen meiner älteren Posts bin ich wieder auf die Output-Filter gestoßen. Und das war hier natürlich auch die Antwort. Folgende Filter musste ich deaktivieren, damit es problemlos geht:
Email, Jquery, LoadOnFly, ScriptVars
So richtig erklären kann man es wohl nicht - vor allem bei E-Mail bin ich ratlos.
Geduld zu haben ist besser, als ein Held zu sein...
(Die Bibel - Sprüche 16,32a)

Online jacobi22

  • Posts: 5599
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Leere Seiten bei größeren Datenmengen?
« Reply #2 on: April 19, 2017, 12:26:19 AM »
Den "Beweis", das der Outputfilter der auslösende Punkt ist, hatte ich schon mehr fach geliefert und wir haben da im engerem Kreis auch schon stundenlang drüber diskutiert. Mein Verdacht geht in Richtung der Datenmenge, die durch den internen Speicher läuft, bevor es letztendlich ausgegeben wird. ScriptVars erzeugt lediglich ein paar Zeilen Code. Wenn das die entscheidenen Zeilen sind, hast du wohl gerade die Grenze des Speichers erreicht. Jquery plus die Scripte, die da mitgeladen werden, sind in der Summe schon einige kb, alle anderen Filter scannen die vermeintliche Ausgabe nach Zeichenketten und ersetzen diese mit den Vorgaben. Das jeweilige Ergebnis landet im Buffer und wird dann im nächsten Filter benutzt für den weiteren Durchgang.
Es ist wohl von Projekt zu Projekt und von Server zu Server unterschiedlich. Drüber gestoplert bin ich bei einem Kalender, wo mal eben 870 A4-Seiten voll Text auf einer Page dargestellt werden sollten. Diese Artikel waren wohl nicht auf Anhieb sichtbar, sind aber, wenn ich sie mit JQuery-Toggle aus- und einblenden möchte, doch im Speicher. Ich kenne auch Projekte, wo die News der letzten 5 Jahre ohne Pagination dargestellt werden sollten.
Man sollte also auch mal über den Sinn solch langer Inhalte nachdenken, viele dieser Probleme sind einfach hausgemacht.
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline suedstaedter

  • Posts: 35
  • Gender: Male
Re: Leere Seiten bei größeren Datenmengen?
« Reply #3 on: April 20, 2017, 10:12:20 AM »
Ja gut, es werden halt erstmal etwa 1.500 Datensätze angezeigt, die dann mittels Formular weiter eingeschränkt werden können. Das Problem ist, dass man als Entwickler schlecht von vornherein eine Einschränkung vorgeben kann.
Ich habe auch schon beim Server den zugewiesenen Speicher für ein Skript hochgesetzt, was aber keinen Erfolg brachte. Außerdem genügt schon einer dieser genannten Filter, um den Effekt zu erzeugen. Deshalb habe ich ja vermutet, dass es bei der Verarbeitung durch die Filter zu diesem Fehler kommt, weil dort evt. etwas unsauber programmiert ist, so dass es in Verbindung mit den großen Datenmengen eben kracht.
Wie ist das beim Umstieg auf 2.10? Wäre dieses Problem dann aus der Welt?
Geduld zu haben ist besser, als ein Held zu sein...
(Die Bibel - Sprüche 16,32a)

Online jacobi22

  • Posts: 5599
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Leere Seiten bei größeren Datenmengen?
« Reply #4 on: April 20, 2017, 12:31:59 PM »
Quote
es werden halt erstmal etwa 1.500 Datensätze angezeigt, die dann mittels Formular weiter eingeschränkt werden können

:-o :-o :-o

Quote
Deshalb habe ich ja vermutet, dass es bei der Verarbeitung durch die Filter zu diesem Fehler kommt, weil dort evt. etwas unsauber programmiert ist, so dass es in Verbindung mit den großen Datenmengen eben kracht.

du bist jetzt der Dritte in der gesamten WB-Geschichte, der das Problem hier schilderte. Wenn ich das durch die gut 1,5 Mio WB-Installationen teile, die es weltweit geben soll, ist das ein sehr geringer Prozentsatz oder anders herum: deine Datenmenge auf dieser Seite weicht schon ziemlich von dem ab, was der Rest in einem CMS benutzt.
Mir war es damals nur möglich, das ganze nachzustellen, nachdem ich das original Datenbank-Backup der Userin bekommen habe. Meine eigenen Versuche, das nach zu bauen, brachten da keine Erfolge, weil ich von meinem Wissen her solch Struktur niemals in der gleichen Art aufgebaut hätte. Ich kann aber auch nicht ausschließen, das ich mit einer moderneren, ressourcen-sparenden Struktur nur die Grenzen etwas hinaus geschoben habe. Vielleicht wäre der Effekt der weißen Seite dann nach 1000 oder 1200 Datensätzen statt nach 870 aufgetaucht. Bei der Userin wurden nur um die 290 Datensätze angezeigt.
Gelöst habe ich das Ganze dann mit einer Pagination plus einstellbarer Zahl für die anzuzeigenen Datensätze pro Seite. Das war ein Kalender mit den Terminen der letzten Jahre. Kennt man das Problem, läßt es sich auch lösen, z.b. mit einer Unterteilung.
Bei dir schaut das eher nach einem riesen Filter aus, wie man es in Shopsystemen findet. Beispiel: Mein amerikanischer Autoersatzteilshop hat um die 80 Auto-Hersteller in der Liste, diese Liste wird gefiltert nach Baujahr, dann nach Modell, dann nach Baugruppe, um dann am Ende irgendwas zwischen einem und 20 Bauteile auszugeben. Das wäre an sich schon eine riesen Datenmenge, wird aber reduziert, in dem er den jeweils angewählten Inhalt, z.b. die Modellpalette dynamisch mit Javascript nach läd. Nach deiner Kurzbeschreibung gehst du wohl den umgekehrten Weg, erstmal alles einlesen und dann Schritt für Schritt z.b. durch Select-Felder reduzieren.

Quote
Wie ist das beim Umstieg auf 2.10? Wäre dieses Problem dann aus der Welt?
Kann man nur testen...  :|
Es hat sich schon einiges geändert an den Filtern, die Reihenfolge (im Vergleich zur WB 2.8.3 SP7), Pflichtfilter wurden integriert statt sie wählbar zu lassen. Der CSStoHead-Filter wurde repariert, ebenso der RELURL-Filter, das Grundprinzip "suche Zeichenkette und ersetze durch Vorgabe" ist aber geblieben, weil es nicht anders geht.
Grundsätzlich muß man aber sagen, das jeder dieser Filter optional ist, keiner davon muß gewählt werden. Mir fehlt z.b. der Sinn, eine Mailadresse zu verschlüsseln, die zum einem eh in tausenden Verzeichnissen steht, zum anderen mit meinem Kontaktformular verlinkt ist und nicht mit einem mailto-Link zum hoffentlich vernünftig eingerichtetem Mailprogramm auf dem Rechner des Besuchers. Aus Bequemlichkeitsgrün den verwende ich wohl den Dropletfilter, könnte aber auch jeden dieser Droplet-Code in einer Code-section laufen lassen.
Unabdingbar ist wohl der ReplaceSysvar-Filter- in WB 2.10.x mittlerweile fest integriert. Ich käme auch ohne aus, müßte aber zu viel umbauen, um es rückgängig zu machen

Deine Filter, die du oben genannt hast

EMail-Filter - scannt die Ausgabe nach Mailadressen und ersetzt jede durch einen per JS verschlüsselten Code, den die Bots (noch) nicht lesen können. Wie gesagt: ich persönlich verzichte in meinen Projekten darauf, verwende ihn aber bei Kunden. Das macht im Höchstfall dort mal 10 Ersetzungen auf einer Teamseite. Es könnten theoretisch aber auch tausende auf einer Seite sein, die alle ersetzt werden müßten. So oder so verbleibt der geänderte Inhalt im Buffer für die nächste Aktion

JQuery - erzeugt, wie gesagt, für das Jquery-Paket mit den 5,6 Dateien, die alle einzeln wiederum weitere Aktionen erzeugen könnten, die erforderlichen Links im Datei-Head und ordnet sie entsprechend ein

LoadonFly - sucht nach (CSS-)Selektoren im Source und läd bei Bedarf die dazu gehörige CSS-Datei nach. Eher marginal - meine ich, zumindest im Basispaket wird ja eh alles fix eingebunden, ist aber dennoch verbrauchter Speicherplatz. Aus meiner Sicht eher ein "Luxusfilter", der mir einiges einfacher machen kann, der sich aber auch gut umgehen läßt. Ich bin da nicht unbedingt der Experte, meine aber, das das aktuelle Umfeld im komplettem System nicht dazu passt, darum ist er eher Balast.
Beispiel: Das Snippet Colorbox läd grundsätzlich die dazugehörige frontend.css, bei idealer Verwendung von LoadonFly würde das CSS dann aber nur geladen werden, wenn auch tatsächlich einer der Selektoren wie z.b. die Klasse "colorbox" im Code gefunden wird. Allerdings müßte man dazu das Umfeld, also das Snippet selber ebenfalls umbauen, wäre dann aber nur noch bedingt in Projekten einsetzbar, die diesen Filter nicht benutzen

ScriptVars - Läd ein paar BasisVariablen zur Nutzung in Javascript. War mal durch die Userschaft gewünscht, um z.b. WB_URL nicht in jedem Addon eigens definieren zu müssen. In den neueren bzw überarbeiteten Modulen ab 2016 wie z.b. die Foldergallery werden aber eigene Scriptvars gesetzt, weil damit Fehler durch Umdefinierung dieser WB-Scriptvars, wie sie in einigen Modulen erfolgen, vermieden werden
Auch hier: eher marginal, aber dennoch im Buffer enthalten, weil ja dieser Scriptblock im Content eingefügt wird, wenn der Filter aktiviert ist.

Nach meinem Verdacht, das der interne Bufferspeicher überläuft, wäre wohl die Frage, ob solch gefilteter Content nach dem Durchlauf im Buffer verbleibt und sich somit addiert oder ob er nach der Generierung des nächsten Contents bzw Filterdurchlaufs aus dem Buffer entfernt wird

Kurzbeispiel: ein Content hat ungefiltert 40kb und nach Filtern und Ersetzen 50kb. Das macht nach dem ersten Durchlauf EMailFilter dann 50kb, nach dem zweiten Durchlauf in der einen Rechnung dann schon 100kb, wenn der zuerst gefilterte Content im Buffer verbleibt. Nach dem dritten wären es dann 150kb - wird der Inhalt des Buffers aber nach jedem Durchgang auf Null gesetzt, sind es nach drei Durchläufen nur 70kb

Ist nur eine fiktive Rechnung ohne praxisnahe Zahlen, keine Ahnung, ob und wie das zu lösen ist. Ich gehe aber davon aus, das andere Systeme genau das gleiche Grundprinzip (Suchen && Ersetzen) benutzen

Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline suedstaedter

  • Posts: 35
  • Gender: Male
Re: Leere Seiten bei größeren Datenmengen?
« Reply #5 on: April 20, 2017, 01:07:38 PM »
Oh, danke für die ausführliche Antwort. Ist mir ja fast peinlich...  :roll:
Aber interessant, was die einzelnen Filter so treiben. Konnte mir unter LoadonFly oder ScriptVars nicht so furchtbar viel vorstellen.
Am einfachsten wird es sein, bei der Datenbankabfrage einfach mal ein Limit zusetzen, um die pure Masse zu begrenzen. Alles klar, danke!
Geduld zu haben ist besser, als ein Held zu sein...
(Die Bibel - Sprüche 16,32a)

Online jacobi22

  • Posts: 5599
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Leere Seiten bei größeren Datenmengen?
« Reply #6 on: April 20, 2017, 01:29:31 PM »
siehe auch

http://forum.WebsiteBaker.org/index.php/topic,29991.msg209374.html#msg209374

weiß nicht, ob ein LIMIT jetzt die Lösung für dich ist, für das Beispiel mit dem Shop wäre es wohl kontra-produktiv.
Für meine Forstmaschinen hatte ich Mitte der 90er mal einen Ersatzteilkatalog programmiert, das waren in Papierform 6 Bücher a ca 500 Seiten. Das Menü dazu war in ähnlicher Form, 1000 mögliche Gruppen in eine Selectbox einlesen und dann nach Auswahl reduzieren und vom Ergebnis wieder 100 Gruppen einlesen, aber das waren eben 1000 oder 100 einzelne Wörter plus einer ID aus einer Datenbank-Tabelle. Mit dem Wissen und den Möglichkeiten von heute würde ich wohl drüber schmunzeln. Damals war es aber so für mich recht praktikabel.

Man müßte mehr davon wissen, was du da verarbeitest und warum das anfangs 1500 Datensätze sein müssen.
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline suedstaedter

  • Posts: 35
  • Gender: Male
Re: Leere Seiten bei größeren Datenmengen?
« Reply #7 on: April 20, 2017, 03:03:22 PM »
Danke für den Link!  (Y)
Und mit dem Limit (samt Hinweis an den Nutzer) kann ich erstmal leben.
Geduld zu haben ist besser, als ein Held zu sein...
(Die Bibel - Sprüche 16,32a)

 

postern-length