Aw: Fehler in Suche

[Ramin Goettlich]

Hallo,

die Performance im Nuclos Client sollte durch grosse Datenmengen grundsätzlich nicht beeinträchtigt sein, da der Client immer nur chunkweise mit Daten versorgt wird (erst beim Runterblättern im Suchergebnis wird chunkweise nachgeladen). Das Problem ist also eher im Server zu lösen.

Auch der Nuclos Server holt sich von der Datenbank nur die Chunks (je nach verwendeter DB ROWNUM-, LIMIT-, TOP-Clause). Das stimmt allerdings nur mit einer Einschränkung: Es werden zwar nur die Dateninhalte des Chunks in das Suchergebnis geladen, allerdings werden beim ersten Aufbau des Suchergebnisses aus verschiedenen Gründen sämtliche IDs aller Datensätze geholt. Diese Einschränkung ist historisch bedingt, eigentlich heute nur noch als Fehler zu betrachten und steht bereits auf der Änderungsliste. Die Ursache für vorliegendes Performanceproblem dürfte das aber nicht sein.

Das Problem ist vermutlich eher in der erlaubten Flexibilität der Suchfunktionen in Nuclos zu suchen. Da man Einschränkungen auf beliebige Spalten (insbesondere mit Wildcards) vornehmen kann (aber eine Indizierung aller Spalten in der DB wenig Sinn macht), lassen sich „full table scans“ kaum vermeiden. Eine Indizierung von Referenzspalten einer Entität macht der Entitätenwizard übrigens standardmässig, eine Indizierung weiterer Spalten kann ebenfalls über den Entitätenwizard erfolgen(Erweiterte Einstellungen). Um das einzuschränken, könnte man eine Suchmaske mit einer geringeren Menge an angebotenen Suchspalten erstellen (welches Layout für die Suche herangezogen wird, lässt sich über die Verwendung im Layout steuern).

Gleiches gilt für die Sortierung im Suchergebnis. Da man nach jeder Spalte sortieren kann, ist die chunkweise Einschränkung der Ergebnismenge für den Datenbankserver irrelevant und nutzlos, da er trotzdem alle Daten verarbeiten muss, um die Sortierung zu erreichen.

Wir schlagen folgende Massnahmen vor:
a) Wenn die Antwort ab einer bestimmten Datenmenge ganz versagt, wäre der erste Vorschlag, den Speicher, der der Datenbank zur Verfügung gestellt wird, sowie den Speicher, der dem Tomcat-Javaprozess zur Verfügung gestellt wird, zu erhöhen. Möglicherweise ist dieser für die zu verarbeitenden Datenmengen zu niedrig angesetzt. Eine Vergrösserung der Hardware und eine Verbesserung der physikalischen Datenbankstruktur (z.B. Partitionierung) wären weitere Möglichkeiten.
b) Nächster Ansatz wären datenbankspezifische Optimierungsmethoden. In Oracle gibt es mE beispielsweise einen Buffer Pool, dem man sagen kann, dass er eine bestimmte Tabelle vollständig im Speicher halten soll.
c) Man sollte die vom Nuclos Server abgesetzten Statements in der DB protokollieren und die Ausführungszeit in Nuclos mit der Ausführungszeit des SQL-Statements direkt auf der DB (SQL-Fenster o.ä.) vergleichen (d.h. wo geht eigentlich die Zeit verloren? welche Statements genau dauern eigentlich so lang?)

Auch sollte man vielleicht über ein fachliche, generelle Einschränkung der Datenmengen über indizierte Felder nachdenken. Sind z.B. die Daten älterer Jahre typischerweise nicht mehr relevant? Greifen bestimmte User immer nur auf bestimmte Datenmengen (z.B. je nach PLZ, Zuständigkeit, etc.) zu? Dafür könnte man das seit 2.7.4 zur Verfügung stehende Feater „Zwangsfilter“ nutzen (je User und Gruppe einstellbar in der Suchfilteradministration) und die Spalten, auf denen man dort einschränkt, in der DB indizieren.

Ach ja: Gibt es berechnete Attribute in der betroffenen Entität? Wir hatten schon Fälle, in denen wir Antwortzeiten von Minuten auf Sekunden heruntergebracht haben, indem wir einfach nur einige berechnete Attribute eliminiert (und die entsprechende Anforderung durch eine benutzerdefinierte View ersetzt) haben. Zumindest bei Oracle (bei anderen DBs weiss ich es nicht) scheint es so zu sein, dass die den berechneten Attributen zugrundeliegenden Funktionen immer aufgerufen werden – unabhängig davon, ob sie Bestandteil der Ergebnisspaltenauswahl sind oder nicht (vermutlich weil sie Exceptions werfen könnten und Oracle das prüfen will).

Zu guter Letzt: Die Suchabfragen laufen in Nuclos immer gegen die Views der Entitäten (wegen der Anzeige der Referenzfelder im Suchergebnis), d.h. es werden momentan Joins durchgeführt, die vielleicht gar nicht benötigt werden, weil manche Felder evtl. nicht Bestandteil des Suchergebnisses sind. Auh hier ist eine Verbesserung der Implementierung geplant, durch die die Entitätenviews durch dynamisch generierte Adhoc-SQL-Statements ersetzt werden – abhängig von der Auswahl der Suchergebnisspalten. Gerade wenn Ihre Entität viele Referenzfelder beinhaltet, und die referenzierten Entitäten viele Datensätze, könnte das ebenfalls eine mögliche Ursache sein.

Grüsse,
nuclosian