Optimierung der Geschwindigkeit
Diese Beschreibung ist in Bearbeitung und gilt nur Versionen höher 25.2.120
Wo liegt das Geschwindigkeitsproblem und wie kann ich es beheben?
Erkennen Sie zuerst wo genau ihr Geschwindigkeitsproblem liegt.
Hierbei muss zwischen "Tile Updater" und "Tile Server" unterscheiden werden.
Tile Updater:
- Erzeugt XML Dateien aus der LOG Tabelle. In den XML Dateien ist definieren an welchen Koordinaten Objekte neu gezeichnet werden müssen
- Sendet die XML Dateien zum Tile Server.
Tile Server:
- Liest die vom Tile Updater erzeugten XML Dateien.
- Berechnet daraus welche Kacheln betroffen sind
- Löscht und erzeugt (rendert) die betroffenen Kacheln neu
Das Optimieren des "Tile Updaters" hat keine Auswirkung auf die Geschwindigkeit des "Tile Server".
Verbringen Sie also nicht Stunden damit den "Tile Updater" zu optimieren in der falschen Hoffnung das der "Tile Server"
damit schneller die Kacheln erzeugt, den der "Tile Updater" erzeugt keine Kacheln.
Wie lange der Tile Server zum Render der Kacheln gebraucht hat sehen Sie im "Tile Server Manager"
Wenn Natürlich die ganze Karte neu gerendert wird dauert es länger als wenn nur einige Kacheln neu erzeugt werden müssen.
Um die Geschwindigkeit des Tile Server zu verbessern lesen Sie bitte:
https://help.mapedit.de/docs/next/Dokumentation/MapEdit-Server/MapEdit-TileServer/KnownProblems
Habe ich ein Geschwindgkeitsproblem mit dem Tile Updater?
- Führen Sie den Tile Updater 2 mal direkt hintereinander aus und schauen Sie danach in das Register "Statistik".
Richtig gelesen, 2 mal! - Für jeden Lauf sehen Sie hier die "Dauer der XML Erzeugung" je Datenbank
- Wenn diese Dauer nur Minuten beträgt dann besteht im Normalfall kein Anlass zur weiteren Optimierung des Tile Updaters. Die dauert ist natürlich abhängig von der Anzahl an Datenbanken, Layern und Datensätzen.
In dem Beispiel oben sehen Sie mehrere Durchläufe. Beim zweiten Durchlauf wurde vom Administrator händisch ein View Optimiert. Beim dritten Durchlauf wurde vom Administrator händisch eine Optimierung mittels Relation Triggern durchgeführt.
Schritt 1: Geschwindigkeitsoptimierung der Views
Im Normalfall sind nicht-optimal definierte Views die Hauptursache einer langsamen Verarbeitung.
Ein optimieren von View empfiehlt sich generell immer, nicht nur im Zusammenhang mit dem Tile Updater, den Langsame Views erzeugen einen Langsamen Bildaufbau, Langsame Masken, ein Langsames Rendern der Kacheln etc.
Führen Sie als erstes im AppBuilder "Views prüfen" in der "Datenbankwartung" aus. Dies ermittelt Defekte und langsame Views.
Reparieren oder entfernen Sie defekte Views.
Im Register "Karten Ebenen" des Tile Updater Dialoges sehen Sie für jede Datenbank in der Spalte "Last Duration" wie lange das Abarbeiten eines Views gedauert hat.
Klicken Sie zwei mal auf den Spaltenkopf um die Views zu sortieren. Sie sehen nun die langsamsten Views zuerst.
Um genauere Werte für eine Optimierung zu bekommen, raten wir dazu den TileUpdater immer zwei mal direkt hintereinander auszuführen und dann erst die Werte zu betrachten.
Wenn ein View hier sehr lange dauert dann ist der View möglicher weise nicht optimal definiert worden.
Bedenken Sie das sich mehrere langsame Views in der Zeit aufsummieren.
Nehmen Sie den View SQL, dieser wird unten Rechts angezeigt, und kopieren Sie diesen in ein AI wie z.B. Microsoft Copilot. Vergessen Sie auch nicht eine Sicherung des Views zu machen.
Sagen Sie dem AI nun "Oracle View optimieren" (bzw. Postgre/SQLite etc)
Das AI wird ihnen dann falls der View noch nicht optimal ist Verbesserungsvorschläge machen. Testen Sie dann den vom AI vorgeschlagenen View das richtige Ergebnis liefert, den auch das AI hat nicht immer recht, und über nehmen Sie den Optimierten View. Nach erneutem Ausführen des Tile Updater können Sie sehen ob sich die Zeit verbessert hat.
Sie können die View SQLs auch im "SQL Query Tool" ausführen z.B. mit select count(*) from ihremview und dort die Zeit beobachten.
Schritt 2: Geschwindigkeitsoptimierung der Synonyme
Auf Synonyme können keine Trigger angelegt werden, d.h. diese werden wie Views behandelt.
Generell raten wir davon ab, in der Karte Synonyme zu externen Datenbanken zu verwenden. Stattdessen sollte – sofern möglich – direkt auf die Tabellen der betreffenden Datenbank zugegriffen werden.
Greift das Synonym auf einen View zu dann gelten die in Schritt 1 genannten Informationen.
Verstehen wie der Tile Updater Views verarbeitet
Auf Views und Synonyme können keine Trigger angelegt werden. Um zu ermittels welche Datensätze sich geändert haben muss der Tile Updater alle Datensätze und Spalten des Views lesen und sich den alten Datenzustand merken. Beim erneuten Ausführen des Tile Updaters muss dieser dann wieder alle Datensätze und Spalten des Views lesen und so mit den neuen Datenzustand herauszufinden. Dann wird der neue und alte zustand verglichen und daraus ermitteln welche Datensätze sich geändert haben. Dies kann natürlich bei langsamen Views oder vielen Datensätzen lange dauern, weswegen diese Vorgehen nicht optimal schnell ist.
Der TileUpdater führt das oben beschriebene vorgehen nur bei Views auf die die Methode "NoTrigger" haben!
Was sind "Relation Trigger"
Wir können auf einen View keinen Trigger anlegen um Änderungen zu finden.
Aber: wir können auf eine der im View beteiligten Tabellen einen Trigger anlegen der dann wiederum die Geometrie aus einer anderen Tabellen ermittelt und diese in die LOG Tabelle schreibt. Damit kann dem Tile Updater bekannt gegeben werden an welcher Geometrischen Stelle geändert wurde ohne das der Tile Updater alle Datensaetze des Views lesen muss.
Beispiel:
Wir haben einen Utility View "VU_BUS_STOP_ATTR" der folgendermaßen aussieht.
SELECT
g.fid,
g.fid_attr,
g.geom,
f.stopname,
f.bench
FROM
bus_stop_attr f,
bus_stop_point g
WHERE
g.fid_attr = f.fid
In dem View sind zwei Tabellen beteiligt. In "bus_stop_point" stehen die Geometrie. In "bus_stop_attr" stehen Attribut Werte wie der Name.
Wir können also nun auf die Tabelle "bus_stop_attr" einen Trigger anlegen der ausgeführt wird wenn sich etwas an der Tabelle "bus_stop_attr" ändert und dann mittels der relation "fid_attr = fid" aus der Tabelle "bus_stop_point" die Geometrie ermittelt und in die LOG Tabelle schreibt.
Geschwindigkeitsoptimierung von Views mittels Relation Triggers
Eine Optimierung mittels "Relation Triggers" ist optional und sollte im Normalfall NICHT durchgeführt werden.
Es dient lediglich dazu, die Geschwindigkeit des erzeugend der XML Dateien zu optimieren.
Dies sollten Sie wirklich nur durchführen wenn die Dauer des Tile Updaters zu langsam ist und wenn Sie genau wissen was Sie tun.
Eine Optimierung mittels "Relation Triggers" ändert nichts an der Geschwindigkeit des Kacheln Renders, den der "Tile Updater" rendert keine Kacheln, das macht der "Tile Server"
Fehlkonfigurationen führen dazu, dass ggf. Kacheln nicht erneuert werden.
Es ist also wenn die "Dauer XML Erzeugung" nicht Stunden beträgt von einer Konfiguration mit "Relation Triggers" generell abzuraten.
Die narrensicherste Methode ist KEINE eigene Konfiguration der "Relation Triggers" vorzunehmen außer das erzeugen der XML Dateien ist am nächsten Tag noch nicht fertig.
Im Register "Karten Ebenen" werden alle Datenbanken aufgelistet welche im Register "Karten" vorhanden sind.
- Für jede Datenbankverbindung sehen Sie hier alle Kartenebenen.
- Je Kartenebene sehen Sie hier welche Tabelle/View und welche Spalten die Kartenebene verwendet.
- Layer vom Typ "Table" sind bereits optimal und können nicht optimiert werden
- Layer vom Typ "View" sind, wenn der View trotz Optimierung des View SQLs langsam ist nicht optimal.
Langsame Views immer zuerst wie in Schritt 1 erläutert optimieren.
Ausgangssituation:
- Einen View VU_BUS_STOP_ATTR für die Darstellung der Bushaltestellen in der Grafik (BUS_STOP_POINT + BUS_STOP_ATTR)
- Utility Punkt Tabelle BUS_STOP_POINT (Bushaltestellen Geometrie)
- Utility Attribute Tabelle BUS_STOP_ATTR (Sachdaten der Bushaltestellen ohne Geometrie)
Im Register "Karten Ebenen" sehen wir den View "VU_BUS_STOP_ATTR" .
Bei Methode steht "NoTrigger", d.h. es müssen immer alle Datensätze verglichen werden. In dem Beispielfall sieht man bei "Last Duration" das die Bearbeitung des Views 0.359 Sekunden gedauert hat. D.h. in diesem Fall ist also keine Optimierung notwendig.
Nehmen wir an bei "Last Duration" würde 15 Minuten stehen. Dann sollte optimiert werden.
Was wir erreichen wollen:
Um das vergleichen aller Datensätze zu vermeiden erzeugen wir einen "Relation Trigger".
Wenn der Anwender in der Attribute Tabelle "BUS_STOP_ATTR" das Feld BENCH oder STOPNAME ändert, dann soll die Geometrie aus "BUS_STOP_POINT" in die Tabelle "ME_TILEUPDATE_LOG" eingetragen werden. Dadurch weis dann das Programm das an dieser Stelle die Kacheln aktualisiert werden müssen.
Markieren Sie den View Datensatz "VU_BUS_STOP_ATTR" Drücken Sie dann den grünen Knopf um einen neuen Relation Trigger hinzu zufügen.
Das Programm macht aufgrund der Tabellen Relationen nun einen Vorschlag was die Geometrie und Trigger Tabelle ist und wie die beiden Tabellen verknüpft sind.
Prüfen Sie diesen Vorschlag oder ändern Sie diesen auf ihre eigene Anforderung.
Die "Trigger Table" ist die Tabelle die bei einer Änderung etwas auslösen (triggern) soll. Also die Tabelle "BUS_STOP_ATTR".
Bei "Geometry Table" muss die Tabelle stehen aus der die Geometrie gelesen werden soll. In diesem Fall "BUS_STOP_POINT".
Der Filter lautet dann in diesem Fall "FID_ATTR={KEY}"
Links bei "Trigger Columns" wählen wir die Felder BENCH und STOPNAME. Nur wenn der Inhalt diese Felder geändert wird soll eine Aktion ausgelöst werden.
FID_ATTR ist der Wert aus der "Geometry Table", "{KEY}" ist ein Platzhalter der vom Programm zur Laufzeit mit der FID von BUS_STOP_ATTR gefüllt wird.
D.h. bei jeder Änderung eines Datensatzes an der Tabelle "BUS_STOP_ATTR" wird intern folgender SQL ausgeführt
select geom from BUS_STOP_POINT where FID_ATTR={KEY}
Bei {KEY} wird vom Programm zur Laufzeit der Wert des Primärschlüsselfeldes der Tabelle BUS_STOP_ATTR (in diesem Fall die FID) eingetragen.
Die Geometrie wird gelesen und in die Tabelle "ME_TILEUPDATE_LOG" eingetragen.
Speichern Sie nun die Einstellung. Beim Speichern legt das Programm nun einen Datenbank Trigger an und Sie sehen einen neuen Eintrag in der Liste der "Relation Trigger"
Drücken Sie nun den Knopf bei "Trigger Table". Dieser öffnet die Datenstruktur und zeigt die Definition der Tabelle "BUS_STOP_ATTR" an. Wechseln Sie nun zum Register "Daten".
Zum testen ändern Sie nun in einen Datensatz den Wert des Feldes "BENCH" um und speichern Sie die Änderung.
Gehen Sie nun zurück in die Tile Updater Konfiguration und dort in das Register "Änderungsprotokoll". Hier sehen Sie nun wenn ihre Einstellungen Korrekt waren den Datensatz im Log.
In der Tabelle "ME_TILEUPDATE_TRG_ERR" sehen Sie zusätzlich wenn Trigger fehlgeschlagen sind.
Relation Trigger werden in der Anzeige immer abhängig vom View angezeigt. Wenn Sie mehrere Layer auf den gleichen View haben werden die gleichen Relation Trigger angezeigt.