performance tabletree widget

[em_we_es]

es sind knapp 15.000 datensätze, die recht schnell bearbeitbar sind. insofern alles i.o.

greift man aber innerhalb eines datensatzes auf den tabletree bei einem datenfeld zu, um eine auswahl aus nur ca. 20 einträgen aus einer anderen datenbank zu treffen, dauert das ewig.
der dialog braucht einfach zu lange.
kann man das beschleunigen?

[em_we_es]

ups, bin ich etwas zu direkt eingestiegen?
im eifer des gefechts habe ich ganz vergessen, dass es beim frontend-edit auftritt.

ich frage mich, warum ein tabletree aus einer anderen datenbank mit 10-15 einträgen immer länger dauert, je größer die datenbank ist, in deren umfeld es aufgerufen wird.
hat niemand sonst hier ein problem mit der performance? das dauert zum teil eine gefühlte ewigkeit, bis der tree im popup aufgeht.
gracie!

[Tim]

Das Tabletree wird für die Tags genutzt. Wir haben in den Demos Tags-Bäume von weit mehr als 100 Tags ohne nennenswerte Latenzen.
Ist der Aufruf aus dem Backend ebenfalls langsam? Worauf greift das Tabletree hier zu? Tags-tabelle
Sicher, dass es nicht Server-Timeouts sind?

[em_we_es]

ich nutze hier den tabletree um statt tags eine andere datenbanktabelle aufzurufen.
hierbei dauert es je länger, je größer die datenbank ist, in der ich den tabeltree aufrufe (nicht relevant aber ist, wie groß der aufgerufene bestand in der tabletree ist)

frontend wie backend:
aufruf eines datensatzes (aus 1500) --> darin aufruf einer anderen tabletree (mit 30 datensätzen): 2 sekunden
aufruf eines datensatzes (aus 15000) -> darin aufruf einer tabletree (mit ca 30 datensätzen) bis zu 16 sekunden … !
auch der editaufruf eines einzelnen datensatzes aus den 15000 dauert relativ gesehen länger als einer aus dem 1500er bestand.

als ob immer der ganze bestand mit einer abfrage durchlaufen werden würde (was in dem moment ja nicht notwendig wäre, wenn es um eine datensatz geht).

mit php 5.x gab es auch fehlermeldung/server error, php7 läuft wesentlich schneller, hängt aber eben noch extrem am tabletree
(16 sekunden sind einfach zu lange, da ist die schwupidzität im eimer).

[Tim]

Du sagst:
Das die Performance der Anzeige des Tags-Felds in Abhängigkeit steht zu der Anzahl an Einträgen in der Tabelle, in der das Tags-Feld liegt. (nicht die Anzahl an Einträgen der Tabelle, die als Auswahl dienen soll und geladen werden müssen). Habe ich das richtig verstanden?

Damit würde sich folgendes auf dem Prüfstand ergeben:
Ein Tags-Feld in einer Tabelle mit 2 Einträgen braucht länger als ein Tags-Feld in einer Tabelle mit einem Eintrag. Bei Darstellung gleichen Inhalts.

[Tim]

Ich habe jetzt einen Test gestartet. Ich habe eine Tabelle mit 30.000 Einträgen angelegt. Jeder dieser Einträge beinhaltet ein Tags-Feld, das ein paar "Werkzeuge" auswählen kann.
Der Performance ist im Millisekunden-Bereich. Contao und CC arbeiten hervorragend.

Die Listen-Ansicht wird von Contao entsprechend limitiert. Auf Bearbeiten-Ebene werden nur die Infos des jeweiligen Eintrags geladen.

[em_we_es]

hallo und danke für den test!
ich wollte gerade antworten, dass es alles so verdrahtet ist, wie angenommen.

wenn ich den debug modus anschalte, bekomme ich beim ersten listing der 15000 datensätze den screenshot anbei.
beim edit eines eintrags gehts nicht mehr weiter mit der fehlermeldung
Fatal error: Maximum execution time of 30 seconds exceeded in /html/contao/system/modules/pct_customelements_attribute_tags/PCT/CustomElements/Attributes/Tags/Tags.php on line 690

[Tim]

Keine Ahnung, was du da aufrufst. Aber wenn deine Tags hier, ohne vorherige Filterung ala "Auswahl einschränken" 15t Einträge laden müssen und diese rendern, bricht sicher das System zusammen. Bei dir werden 87.000 Datenbankabfragen gestartet!

[Tim]

So, das Limit wird aber nicht durch das Tabletree ausgerufen, sondern: Du versucht hier die gesamte Tabelle im Backend nach einem Tags-Feld zu sortieren. Bei der Masse ein Einträgen bricht dein Server zusammen. Deaktiviere die Backend-Sortierung für die Tags-Felder!

[em_we_es]

ich gehe in der datenbanktabelle auf den ersten screen.
da sind im contao dreissig ja standardmässig ausgewählt.
dann rufe ich einen datensatz auf -> fehler bei aktiviertem backend-debug-modus.
ohne den dauert es eben sehr lange, bis der datensatz angezeigt wird und ein aufruf eines tag-felds mit verknüpfter anderen datenbank dauert auch nochmal so lange.
ich sehe da nichts, was ich speziell verbogen haben könnte.

[Tim]

Siehe: http://forum.premium-contao-themes.c...1020#post11020

Für das Popup relevant: Wieviele Datensätze befinden sich in cc_dienstbezeichnungen?

[em_we_es]

… das ist ja das komische.
es sind nicht sehr viele, die da innerhalb eines einzelnen datensatzes aufgerufen werden müssen.

[Tim]

Das Timeout entsteht durch eine aktive Backend-Sortierung auf ein Tags-Feld. Lösche deine Benutzer-Session: Benutzer > Session-Daten leeren.
Achte darauf auch kein Tags-Feld als Standard-Sortierung aktiv zu haben.

[em_we_es]

ui, es tut sich was. ich habe alle sortierungen und such-felder rausgenommen.
von über 70.000 auf 24.000 abfragen runter …
im frontend bewirkt das beim edit ebenso, dass alles viel schneller geht.

dennoch dauert es bei dieser abfrage hier z.b. noch seltsam lange.
drei treffer (aus einer liste von 2500) ergeben 5ms.

[Tim]

Hier werden weiterhin viel zu viele Abfragen gestartet. Davon abgesehen sind 5s bei 2500 Einträgen ein guter Wert. Du solltest auch Backend-Filterungen auf Tags-Felder vermeiden, falls aktiv. Dafür ist die Masse schlichtweg zu groß. Filterungen und Sortierungen dieser speziellen Felder unterliegen keinem Limit. Es müssen ALLE Einträge durchlaufen werden.

Du kannst Suchfelder schon drin lassen, wenn es Felder sind, die quasi leserlich in der Tabelle direkt speichern z.B. reine Textfelder. Tags sind blobs, die müssen zerlegt werden und entsprechend aufgebröselt werden. Das macht es aufwendig.