Plugin Content Data View: Extrem lange Ladezeiten bei vielen Daten

Hallo,
ich setze das Plugin Content Data View für die Ausgabe von Ergebnislisten einer Laufveranstaltung ein. Im Prinzip eine tolle Sache, nur mit Zunahme der Einträge entstand ein massives Performance-Problem.

Das Formular hat mittlerweile 1.600 Einträge.
Mittels fieldselect wird ausgewählt welche Einträge angezeigt werden (z.B. nur Bewerb Marathon und nur Frauen).

Nur steigt mit der Anzahl der Formulareinträge die Ladezeit (v.a. TTFB) massiv an, unabhängig davon ob über den Filter nun nur ein Eintrag oder 1.000 Einträge gelesen werden.

Hier ein Beispiel:
www.hdsports.de/wettkampf/1-anti-corona-run-ergebnisse?start=1

Code
Ich habe bisher über die Filtereinstellungen keine Möglichkeiten gefunden, das Problem zu heben. Den Filter zu löschen (fieldselect) erhöht die Ladezeit nur noch mehr, display_num auf nur 5 zu stellen, ändert ebenfalls nichts an der Ladezeit. Ich könnte den Code auch auf das Mindeste reduzieren, wie etwa: Es ändert sich aber nichts an dem Problem mit der Ladezeit.

Ich bin kein Experte und das sich die Ladezeit beim Auslesen der Daten leicht erhöhen kann, wenn mehr Daten vorhanden sind, ist mir bewusst, aber solch eine derart lange Ladezeit halte ich für ungewöhnlich bzw. ist nicht im Sinne des Nutzers. Ich wollte mir über "System debuggen" die Abfrage ansehen, nur erhalte ich dann leider ein weißes Fenster (das allerdings nur bei Artikel, wo vfdataview im Einsatz ist.

LG

Hallo,

danke für deinen Beitrag.

Die Ladegeschwindigkeit ist ein komplexes System und ich habe mir über deinen Post eine ganze Menge Gedanken gemacht.

An erster Stelle ist visForms eine Formularkomponente mit der Möglichkeit die übertragenen Daten auch zu speichern und zu nutzen.
Bei der Entwicklung gibt es immer wieder widerstreitende Interessen der unterschiedlichen Feature und eine Entscheidung zu gunsten von Feature A zu treffen, kann bedeuten, dass man bei Feature B Abstriche machen muss.

Bislang hat niemand von einem solchen Performance-Problem berichtet und ich denke, dass es wahrscheinlich auch nur ganz wenige visForms Installationen gibt, in denen in einem Formular so viele Datensätze gespeichert werden. Es ist also in der Praxis ein sehr seltener Use-Case. Und visForms ist hierauf nicht optimiert.

Insgesamt ist visForms so optimiert, dass es im Hinblick auf die Erstellung und Nutzung des Formulars besonders flexibel ist und hier besonders viele Feature bietet.
Dies kommt im Bereich der Datenhaltung und -nutzung zu einem Preis.

Hast du dich bei den Joomla! Custom Fields schon einmal darüber geärgert, dass du den Feldtyp nachträglich nicht mehr ändern kannst?
Für eine Formularkomponente wie visForms ist das meines Erachtens ein no-go und deshalb kannst du bei visForms prinzipiell auch immer den Typ eines Feldes ändern.
Die Konsequenz dieses Features ist, dass die Datenbankfelder in denen die Formulardaten gespeichert werden, bei allen in visForms angelegten Feldern, immer den Datenbank-Feldtyp "Text" haben.
Zu versuchen, einen Formularfeldtyp angepassten Datenbankfeldtyp zu verwenden (z.B. Zahl im Formular und int in der Datenbank), würde bedeuten, dass man bei jeder Formularfeldtyp-Änderung auch den Datenbankfeldtyp anpassen muss und das macht die Sache auf jeden Fall super aufwendig.

Gute Performance auf großen Datenmengen erreicht man, indem man wichtige Datenbankfelder indiziert.
Datenbankfelder vom Typ Text können aber nicht indiziert werden.

Ein zweiter "Problempunkt" sind die Formularfelder mit Optionen, bei denen eine prinzipiell Mehrfachauswahl einstellbar ist (Listbox, Checkbox-Gruppe).
Prinzipiell werden hier alle gewählten Optionen in einem Datenbankfeld aggregiert gespeichert.
Will ich nun über eine Filtereinstellung in einem SQL-Where Statement nur die Datensätze aus der Datenbank ziehen, die in diesem aggregierten Wert eine bestimmte Option enthalten, dann fürhe ich in dem SQL-Where Statement einen Textvergleich durch und das ist bekanntlich ein "teuer" Zugriff.
In deinem Fall sind 2 solcher Filter bereits im Plugin-String eingebaut.

Ich gebe auch gerne zu, dass optimale Performance bei großen Datenmengen bei der Entwicklung der Datenanzeige-Feature und besonders auch der Daten-Filter nicht mein Hauptentwicklungsschwerpunkt war.

Ich weiß nicht, ob das gesamte Performance-Problem bei der Datenanzeige auf deiner Webseite allein durch visForms selbst erzeugt ist oder ob da auch noch andere Faktoren rein spielen, aber dass die Performance bei einer großer Anzahl an Datensätzen und komplexen Filtern spürbar schlechter wird, das ist sicher richtig.

Ich gehe davon aus, dass, wenn ich den entsprechenden Code unter dem Aspekt der Performance-Optimierung durchgehe, sich die Performance sicher verbessern lässt.
Ich werde das auf meine ToDo-Liste setzen und mich zu gegebenem Zeitpunkt damit befassen.

Es tut mir leid, das ich im Moment keine bessere Nachricht für dich habe.
Vielleicht helfen dir meine Ausführungen einen Weg zu finden, deinen Seite so aufzubauen, dass du nicht in dieses Performance-Problem läufst.

Gruß,
Aicha

Hallo Aicha,
danke für die ausführliche und erklärende Antwort.

Dann werde ich vorerst pro Lauf und pro Geschlecht ein eigenes Formular verwenden. Dann benötige ich bei einem Event mit 10 Bewerben zwar 20 Formulare. Die Ladezeit sollte allerdings aufgrund der geringeren Anzahl an Einträgen pro Formular und der reduzierten Anzahl an Listboxen (Geschlecht, Bewerb benötige ich nicht mehr) deutlich kürzer sein.

LG und schönes Wochenende

Eine wichtige Anmerkung, die mir aufgefallen ist:

Die lange Ladezeit kommt bei mir vor allem deswegen zustande, da ich auf der bisherigen Ergebnisseite, den vfdataview-Code mehrmals integriert habe (Marathon Herren, Marathon Damen, Halbmarathon Herren usw).

Zwar hatte ich für die einzelnen Bewerbe "Seitenumbrüche" verwendet, trotzdem werden beim Aufruf einer Unterseite alle Abfragen ausgelöst. Nun habe ich für jeden Bewerb einen neuen Beitrag verwendet, mit dem Resultat einer deutlich geringeren Ladezeit (TTFB) als bei einem Beitrag mit Seitenumbrüchen. Bei einigen hundert Einträgen steigt zwar auch hier die Ladezeit an, aber in einem deutlich erträglicherem Maße als bisher.

Hallo,

danke für diese Zusatzinformation.
Das ist gut zu wissen.

Gruß und frohe Ostern,
Aicha