Performanceproblem bei vielen Relationen

ukulele · 10. Januar 2021 um 16:18

Guten Morgen zusammen,

ich habe mich etwas in die Idee verrannt mit Combit CRM meine Netzwerk-/Patchplanung zu erneuern. Gestern habe ich mir einen Prototypen gebaut der eigentlich super funktionieren könnte. Ich möchte unbedingt für die visuelle Darstellung eine Switch-/Patchfeld-Ansicht ermöglichen, dazu hatte ich 56 Fremdschlüssel vorgesehen die auf den selben Primärschlüssel zeigen (natürlich würde man sowas normalisiert in einer Zwischentabelle abbilden aber dann kriege ich die halt nicht auf eine Maske). Mit 4 Stück klappt das alles super, bei 20 habe ich schon derbe Ladezeiten. Dazu zwei Fragen:

a) Ich habe nur 16 weitere Schlüssel in der Maske angelegt, die Schlüssel in der Maske aber noch nicht verwendet. Dennoch läd die Maske länger. Das ist noch verschmerzbar, mit 24 wäre das noch machbar. Ich würde gerne besser verstehen was dabei die Ladezeit bestimmt und ob ich die irgendwie noch beeinflussen kann.

b) Das größere Problem ist tatsächlich ein Anderes. Es gibt noch eine 1:n-Beziehung in einer anderen Ansicht mit nicht so vielen Beziehungen aber auf die selbe Spalte. Sobald hier der Container aufgerufen wird lädt der bestimmt 15 Sekunden. Das kann ich mir überhaupt nicht erklären da es sich um eine eigenständige Maske in Combit CRM handelt und die Relationen aus der anderen Maske aus meiner Sicht keine Auswirkungen z.B. auf die Datenbank haben.

Natürlich sind die beiden Masken über Relationen verbunden aber warum beeinflusst der Umfang der einen Maske die Ladegeschwindigkeit einer anderen Maske?

Ich nutze noch immer CRM 6, natürlich erwarte ich da keinen offiziellen Support. Vermutlich sind die Mechanismen aber nach wie vor die Selben. Ich denke ich werde auch mal eine Teststellung von CRM 10 ausprobieren, das wird aber noch etwas dauern. Wenn jemand Tipps für mich hat würde es mich freuen.

beggstein · 11. Januar 2021 um 11:49

Hallo „Ukulele“,

das Hinzufügen von auf sich selbst zeigenden 1:1 Relationen führt zu exponentiellem Wachstum der so im Datensatz „vorhandenen“ Felder und das explodiert bei Ihnen.

Um das zu verstehen, muss man wissen, dass der cRM 1:1 Relationen über zwei Stufen hinweg automatisch auflöst und diese Felder in den Ausgangsdatensatz „hineinprojiziert“, so dass diese 1:1 Felder genau so verwendet werden können, als wären sie Felder der Ansicht selbst. So ist es eben sehr komfortabel möglich, für einen Kontakt per „Firma.Firma“ (technisch lautet der Name „CompanyID.Firmen.ID.Company“) direkt auf den Name der zugehörigen Firma zuzugreifen.

Dieser Komfort hat einen Preis: Wenn Sie EINE rekursive - also auf sich selbst zeigende - 1:1 Relationen anlegen, dann katapultieren Sie mit einem Schlag (mit einem FK-Fremdschlüsselfeld) direkt die Anzahl der „Gesamt“-Felder für Datensätze dieser Ansicht auf das DREIFACHE. Nämlich:

Direkte-Felder-des-Datensatze
plus Felder-des-per-Fremdschlüssel-verlinkten-Datensatzes
plus Felder-des-dort-wiederum-per-Fremdschlüssel-verlinkten-Datensatzes (der cRM löst wie gesagt 2 Stufen auf).

D.h. jedes rekursive FK-Feld führt zu einem quadratischen Wachstum der Anzahl von Feldern gemäß folgender Formel:

Anzahl_Direkter_Felder x (1 + Anzahl_Rekursiver_FK_Felder + Anzahl_Rekursiver_FK_Felder^2)

Also führt dies bei einer Ansicht mit beispielsweise 60 Feldern und davon 56 Fremdschlüsselfelder, die auf die Ansicht selbst wiederum verweisen, dann zu einer „effektiven Breite“ des Datensatzes von 188.217 Feldern!!

Faustregel: alles über 4000 Felder ist nicht gut und das Datenbankdesign sollte aus Performancegründen überdacht werden.

Im cRM werden übrigens im ‚Datei > Hilfe > Info > Support-Info‘-Dialog die effektive Breiten der Datensätze der Ansichten dargestellt:

Wir haben seit Version 6 sehr viel Anstrengungen unternommen, um hier maximale Performance herauszubekommen (selbst 4.000 Felder sind ja ne echte Hausnummer), Datenbankabfragen so spät wie möglich zu machen, das Datenbankschema selbst zu cachen, um für 4.000 Feldnamen, Längen, Typen nicht die Datenbank zu belasten etc. pp. D.h. der Geschwindigkeitsunterschied von cRM6 zu cRM10 sind bei vielen 1:1 Feldern in einer Ansicht sicherlich „Lichtjahre“ (und auch unter anderen Geschwindigkeitsaspekten). Dennoch muss man ehrlicherweise sagen: das was Sie da vorhaben würde gemäß obiger Formel vielleicht für 10 rekursiven Fremdschlüsselfelder bei 60 Feldern in der Ansicht noch funktionieren (=6.660 Felder) - jedenfalls mit Version 9 oder Version 10 - Ihre Version 6 wird auch das nicht halbwegs praktikabel benutzbar packen.

Sie können sich mit einem Trick noch behelfen, indem Sie 1 Zwischenansicht dazwischenschalten, d.h. die Relation zeigt nicht auf sich selbst, sondern auf eine Verknüpfungsansicht und dort dahinter ist dann erst die Verknüpfung zurück auf die eigentliche Ansicht. Das dämpft das exponentielle Wachstum, da der cRM ja nur über maximal 2 Stufen auflöst.

Ich hoffe ich konnte Ihnen ein wenig weiterhelfen!

Allen einen Guten Start ins Neue Jahr!

ukulele · 11. Januar 2021 um 14:51

Super Antwort danke, viel ausführlicher als ich es erwartet hätte

Im Prinzip ist seit Sonntag Morgen viel passiert. Ich habe mir das weitest gehend selbst zusammen reimen können, denn: Am Sonntag hatte ich zu meinen 20 Test-Relationen noch 4 dazu gepackt (denn, ist ja klar, 24 passt besser ) und dabei hat sich die Masken.dli auf über 210.000 Zeilen und über 11,5mb vergrößert. Dabei ist mir der beschriebene Umstand klar geworden. An der Stelle hat Combit dann auch beschlossen die Masken.dli zu löschen, ich glaube die wurde zuvor nicht komplett vom Editor gespeichert. Habe die erst wieder aus dem NTFS gelöscht Zustand „retten“ müssen.

Interessant ist das allemal, mir war nicht bewusst das tatsächlich jeder theoretische Pfad bis auf zwei Rekursionsschritte runter gebrochen wird und die daraus resultierende Liste an Feldern in der Masken-Konfigurationsdatei gespeichert wird. Das ist aber deutlich nachvollziehbar. Zunächst legt man die Relationen an, die Masken.dli bleibt aber klein. Erst der Editor ließt die Pfade aus und ballert das in die Datei. Jetzt die Frage, läuft die Datei auch noch wenn ich nicht benötigte Pfade raus editiere? Also eine fertige Maske nehme, mit dem Editor nicht mehr anfasse sondern von Ballast befreie. Das werde ich ausprobieren, allein schon aus Neugirde.

Version 10 werde ich mir als Teststellung holen sobald ich die Ruhe finde. Dann werde ich die Perofrmance an diesem konkreten Fall testen.

Das das DB-Design verbesserungswürdig ist stimmt schon, leider kriege ich das nicht anders gelöst. Ich möchte eine Art visuelle Patch-Übersicht in der Maske nutzen um die Ports anzuzeigen und „klickbar“ zu machen. Ich beschränke mich jetzt auf je 24 Ports pro Ansicht, also ggf. teile ich Switches auf mehrere Einträge auf. Bisher läuft das, abgesehen von der Geschwindigkeit bei 1:n-Beizheungen, doch recht angenehm. Auf eine andere Ansicht könnte ich verweisen, aber dann könnte ich nicht den nächsten Port anklicken und hätte nach wie vor die selbe Maske auf.

Im Bild ist Port 15 ausgewählt (blau), ich kann aber in jedem Datensatz in der Maske alle Ports des Switches direkt anklicken, daher die 24 1:1-Beziehungen mit sich selbst.

beggstein · 11. Januar 2021 um 16:35

Wow - die Maske sieht super aus! Man sollte nicht glauben, dass es sich um ein CRM Framework handelt.

Also in cRM10 werden nur die wirklich benutzten Felder gespeichert, das war in cRM6 noch anders. D.h. eine cRM10 Eingabemaske ist von Haus aus schlanker als eine cRM6 Eingabemaske. Manuell mit einem Editor rauslöschen (gegebene XML Struktur inkl. der Einrückungen nicht verletzen!) geht, aber Ihr Problem ist nicht so sehr die .DLI Dateigröße, sondern einfach die schiere Anzahl der Felder, die beim Laden der Maske in die Maske hinein „angemeldet“ werden, damit die Eingabemaske überhaupt weiß aus welchem „Pool“ an Feldern sie schöpfen kann. (Es könnten ja Felder in der zugrundeliegende Datenbanktabelle entfernt oder hinzugefügt worden sein.) Und diese Schleife des Anmeldens (und hierzu der Datenbankabfrage von Feldlängen, Feldtypen etc.) dauert einfach seine Zeit bei zig-tausendenden von Feldern. Darauf hat das Löschen von „unbenutzten“ Feld-Informationen aus der DLI Datei keinen Effekt. Das Öffnen der Ansicht als Übersichtsliste dauert genau so lange.

Bei cRM6 dauert insgesamt alles noch viel länger, cRM10 initialisiert nur die Ansichtsart, die auch wirklich dargestellt wird, cRM6 hat immer sowohl Eingabemaske als auch Übersichtsliste initialisiert, egal ob sie jemals angezeigt wurde, oder nicht.

Wenn Sie mögen, schließen wir uns per PN kurz und ich sage Ihnen wie lange das Öffnen Ihre Solution in cRM10 dauern wird - wir bräuchten halt Ihre Solution (anonymisiert oder reduziert auf diese Ansicht oder geleert, denn die eigentlichen Datensatzinhalte sind ja nicht das Problem), das würden wir kurz per PN besprechen, und ich würde das Messergebnis dann hier reinstellen, damit alle im Forum was davon haben. (Ob wir einen identischen Vergleich mit cRM6 auf derselben Maschine hinbekommen, kann ich nicht versprechen, ich muss bei uns erstmal jemand finden, der mit unserer aktuellen Infrastruktur diese fast 10 Jahre alte Version noch am Fliegen hat.)

Disclaimer: Zaubern kann auch die V10 nicht - am Ende des Tages müssen irgendwie die 8.000 (? wieviel sind es denn nun?) Felder halt „rüber“ in die Maske

ukulele · 11. Januar 2021 um 21:27

Auch das kann ich bestätigen. Habe aus der Maske per Editor ca. 35.000 -Elemente entfernt, die bleiben auch weg solange ich den Editor ruhen lasse. Die Ladezeiten beeinflusst das gar nicht.

Die Anpassungen in CRM10 scheinen sehr sinnvoll. Kann ich da zufällig einer Relation auch eine weitere Rekursionsstufe folgen? Den Fall brauchte ich nämlich auch schon das ein oder andere Mal.

Ich denke ich werde meine Maske im laufe der nächsten zwei Woche noch etwas pimpen, diverse offene Punkte abfrühstücken und dann für einen Test rüber schicken, oder eben selber CRM10 aufsetzen. Die CRM6 Performance ist unterirdisch, das braucht keiner testen das kann weiß ich wohl schon

ukulele · 26. Februar 2021 um 13:05

Ich habe mit meiner Combit 10 Testversion heute mal etwas gespielt. Es ergeben sich definitiv Perofrmance-Vorteile, die scheinbar teilweise auch auf Caching nach dem ersten laden der Maske beruhen. Wenn ich eine Ansicht mit 24+ Relationen öffne dauert das schon noch. Auch wenn ich dann erstmalig einen Container anzeigen lasse. Wechsel ich dann aber den Datensatz in der Tabelle läd alles, inkl. Container schnell.

Das einzige was zwar schneller aber immernoch nervig lange dauert ist die Funktion „Relationaler Datensatz zuordnen“ auf der Maske mit einer Relation auf die Tabelle. Das ist nach wie vor sehr unangenehm und beim 2ten Aufruf ohne Wechsel des Datensatzes unverändert schnell / langsam. Da hab ich noch nicht so recht eine Idee.

beggstein · 26. Februar 2021 um 13:10

Mein Angebot steht noch. Sie lassen mir die(sen Teil der) Solution zukommen, und ich lass mal prüfen, was es mit der relationalen Datensatzauswahl in Ihrem Fall auf sich hat. Schicken Sie mir ne mail an eggstein@combit.net und wir stimmen uns damn ab.