Performance Problem Auto-Query / Filter / L2 Cache

Description

Der Issue steht auf "Critical" und wurde als "Task" erstellt, weil wir dies unbedingt untersuchen müssen. Bei einem Kunden mit Supportvertrag wird dabei die Anwendung bereits abgeschossen! Evtl. gibt es hierfür auch einen Workaround.

1. Das Projekt "Test" im Anhang importieren.
2. Die View "TestFilter" starten.
3. In der Table komplett nach unten scrollen.
4. Einen Datensatz selektieren.
5. Im Filter "d" eintippen.
6. Die Eingabe im Filter wieder löschen.
7. Jetzt eskalieren die Datenbankabfragen.

So wie ich das sehe wird der Cache komplett gefüllt (Auto-Query Data wird verwendet). Bei der kleinen Testanwendung noch nicht so schlimm.
Beim Herrn König von Cobinet stürzt aber der Server ab, da der Speicher überläuft.

Es muss geprüft werden, warum beim Filter löschen und die Konstellation von oben die komplette Tabelle abgefragt wird.

Ich habe hier lokal auf meinem System von Herr Hahn auch eine sehr große MySQL Datenbank. Gerne stelle ich diese zur Verfügung für den Test:

Server: 192.168.86.98
Benutzer: test
Passwort: test
Datenbank: hahn

Tabelle: artikel (21.100 Einträge)
Tabelle: rech_pos (1.123.877 Einträge)

Spätestens wenn man mit diesen Tabellen das Beispiel durchführt ist auch bei Lazy-Loading (Auto-Query Data) die Anwendung kaputt.

Auch hier hängt ein Beispiel mit dran "HahnTest" > "MainView".

Anbei auch noch die Auswertung vom Beispielprojekt Test und den einzelnen Schritten:

Anwendung starten:

Session Metrics
78004 nanoseconds spent acquiring 1 JDBC connections;
146070 nanoseconds spent releasing 1 JDBC connections;
1526660 nanoseconds spent preparing 18 JDBC statements;
11490138 nanoseconds spent executing 18 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
77854428 nanoseconds spent performing 66 L2C puts;
847809 nanoseconds spent performing 2 L2C hits;
1007432 nanoseconds spent performing 18 L2C misses;
32593496 nanoseconds spent executing 1 flushes (flushing a total of 67 entities and 69 collections);
9035 nanoseconds spent executing 1 partial-flushes (flushing a total of 0 entities and 0 collections)

Scrollen in der Table nach ganz unten:

Session Metrics
127397 nanoseconds spent acquiring 1 JDBC connections;
249976 nanoseconds spent releasing 1 JDBC connections;
2604568 nanoseconds spent preparing 31 JDBC statements;
22308960 nanoseconds spent executing 31 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
108036117 nanoseconds spent performing 108 L2C puts;
3598743 nanoseconds spent performing 24 L2C hits;
1062247 nanoseconds spent performing 31 L2C misses;
3975815 nanoseconds spent executing 1 flushes (flushing a total of 129 entities and 116 collections);
15673466 nanoseconds spent executing 3 partial-flushes (flushing a total of 148 entities and 148 collections)

Datensatz selektieren

Session Metrics
109628 nanoseconds spent acquiring 1 JDBC connections;
203594 nanoseconds spent releasing 1 JDBC connections;
0 nanoseconds spent preparing 0 JDBC statements;
0 nanoseconds spent executing 0 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
0 nanoseconds spent performing 0 L2C puts;
0 nanoseconds spent performing 0 L2C hits;
0 nanoseconds spent performing 0 L2C misses;
0 nanoseconds spent executing 0 flushes (flushing a total of 0 entities and 0 collections);
0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections)

Filter nach "d":

Session Metrics
346954 nanoseconds spent acquiring 1 JDBC connections;
231604 nanoseconds spent releasing 1 JDBC connections;
7095087 nanoseconds spent preparing 40 JDBC statements;
26666662 nanoseconds spent executing 40 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
120008140 nanoseconds spent performing 114 L2C puts;
5918395 nanoseconds spent performing 40 L2C hits;
914368 nanoseconds spent performing 40 L2C misses;
1852830 nanoseconds spent executing 1 flushes (flushing a total of 149 entities and 120 collections);
11897330 nanoseconds spent executing 5 partial-flushes (flushing a total of 263 entities and 263 collections)

Filter löschen:

Session Metrics
294248 nanoseconds spent acquiring 1 JDBC connections;
101798 nanoseconds spent releasing 1 JDBC connections;
44294152 nanoseconds spent preparing 947 JDBC statements;
531143799 nanoseconds spent executing 947 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
3046185528 nanoseconds spent performing 3126 L2C puts;
19160172 nanoseconds spent performing 219 L2C hits;
8495537 nanoseconds spent performing 953 L2C misses;
5467236 nanoseconds spent executing 1 flushes (flushing a total of 3200 entities and 1152 collections);
435846194 nanoseconds spent executing 145 partial-flushes (flushing a total of 242142 entities and 242142 collections)

Session Metrics
87642 nanoseconds spent acquiring 1 JDBC connections;
237929 nanoseconds spent releasing 1 JDBC connections;
0 nanoseconds spent preparing 0 JDBC statements;
0 nanoseconds spent executing 0 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
0 nanoseconds spent performing 0 L2C puts;
133466780 nanoseconds spent performing 3344 L2C hits;
369540 nanoseconds spent performing 144 L2C misses;
7472160 nanoseconds spent executing 1 flushes (flushing a total of 3200 entities and 1152 collections);
399867785 nanoseconds spent executing 144 partial-flushes (flushing a total of 242130 entities and 242130 collections)

Session Metrics
91256 nanoseconds spent acquiring 1 JDBC connections;
139444 nanoseconds spent releasing 1 JDBC connections;
0 nanoseconds spent preparing 0 JDBC statements;
0 nanoseconds spent executing 0 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
0 nanoseconds spent performing 0 L2C puts;
125856337 nanoseconds spent performing 3344 L2C hits;
345454 nanoseconds spent performing 144 L2C misses;
7233328 nanoseconds spent executing 1 flushes (flushing a total of 3200 entities and 1152 collections);
384966525 nanoseconds spent executing 144 partial-flushes (flushing a total of 242125 entities and 242125 collections)

Environment

None

Activity

Show:
Sebastian
April 3, 2017, 1:28 PM

Auch mit aktivieren MultiSelect ist die Performance jetzt in Ordnung.

Sebastian
March 31, 2017, 1:19 PM

Folgende Zeile hat auch deselektiert:

this.table.setValue(null);

Weitere Auswirkung unbekannt

Sebastian
March 31, 2017, 1:10 PM

Ich habe es mal in einer Beispiel-Anwendung getestet und bei Multiselect greift select(null) bzw. unselect(null) nicht. Folgendes klappt:

Sebastian
March 31, 2017, 1:00 PM

Mit der Standardkonfiguration Table + Filter funktioniert jetzt alles wie gewollt. Aktiviere ich bei der Table die Eigenschaft "MultiSelect" und wie oben beschrieben Punkt 1-7 nochmal durch, dann tritt das Problem noch auf.

Florian
March 28, 2017, 2:28 PM

Quick-Fix: Selektierung bei Container-Inhaltsänderung löschen:

Das Framework können wir evtl. als 3.0.3 releasen.

Fixed

Assignee

Florian

Reporter

Sebastian