Dieser Artikel zeigt Administratoren, IT-Mitarbeitern oder anderem technischem Personal, das die Bereitstellung des utility network unterstützt, wie man Protokollinformationen interpretiert, die speziell für dessen Workflows relevant sind. An einigen Stellen ist dieser Artikel sehr technisch und erfordert ein fundiertes Verständnis der Konzepte und Technologien, die zur Beschreibung des utility network verwendet werden.
Bearbeiten: Wenn Sie Ihre eigenen Protokollanalysen durchführen möchten, finden Sie die Beispiel-Python-Tools hier, mit denen die Diagramme in diesem Artikel erstellt wurden.
Dieser Artikel wurde verfasst, um Administratoren, IT-Mitarbeitern oder anderem technischem Personal, das die Bereitstellung des utility network unterstützt, zu helfen, Protokollinformationen zu verstehen, die speziell für dessen Workflows relevant sind. An einigen Stellen ist dieser Artikel sehr technisch und erfordert ein fundiertes Verständnis der Konzepte und Technologien, die zur Beschreibung des utility network verwendet werden.
Um diesen Artikel zu verstehen, müssen Sie zuerst den Utility Network Diagnostics-Artikel gelesen haben und mit ihm vertraut sein. Dieser Artikel beschreibt, wie man Protokollinformationen für verschiedene utility network-Operationen erfasst. Dieser Artikel baut auf diesen Konzepten auf, indem er einige Tipps zur Interpretation dieser Protokolle gibt und wie Leistungskennzahlen extrahiert werden können, um die Leistung Ihres Systems zu bewerten. Diese Protokolle ersetzen keine Tools wie ArcGIS Monitor, ermöglichen es Ihnen jedoch, tiefer einzutauchen und potenzielle Leistungsengpässe zu untersuchen.
Warum ist das wichtig?
Zu wissen, wie man Leistung präzise misst und bewertet, ist eine wichtige Fähigkeit, da sie es Ihnen ermöglicht, die Auswirkungen Ihrer Datenmodellierungs- oder Architekturentscheidungen zu quantifizieren. Eine Sammlung von Ressourcen, die die Auswirkungen dieser Entscheidungen diskutieren, finden Sie im Fazit dieses Artikels.
Hinweis: Dieser Artikel zeigt Screenshots verschiedener Diagramme und Protokolle, enthält jedoch keine Beispieldaten zum Arbeiten. Die Diagramme verwenden unterschiedliche Datensätze und Skalen und sollten nicht zur Ableitung von Schlussfolgerungen verwendet werden. Sie sollten Tests mit Ihren eigenen Daten durchführen, um mithilfe der in diesem Artikel beschriebenen Techniken Schlussfolgerungen zu ziehen. Die in diesem Artikel gezeigten Protokolle stammen aus ArcGIS Enterprise 12.1; neuere oder ältere Versionen können andere Meldungen anzeigen. Die genaue Formulierung und Struktur der Protokolldateien ändert sich mit jeder Version, weshalb es wichtig ist zu verstehen, wie man Protokolle interpretiert anstatt spezifische Meldungen auswendig zu lernen.
Eine weitere wichtige Erkenntnis aus diesem Artikel ist es, darüber nachzudenken, wie Protokolle verwendet werden. Sie sind ein wichtiges Werkzeug zur Fehlerbehebung und können auch zeigen, welchen Einfluss Datenmodellierungsentscheidungen, Konfiguration oder sogar Architektur auf die Leistung und das Endbenutzererlebnis haben können.
Serverprotokolle liefern detaillierte Informationen, mit denen Sie die Leistung bestimmter Operationen messen können und in vielen Fällen auch erlauben, Leistungsbeeinträchtigungen bestimmten Subnetzen oder der Anzahl der von dieser Operation betroffenen Features zuzuordnen. Ein Beispiel dafür, warum dies wichtig ist: Stellen Sie sich vor, ein Benutzer beschwert sich darüber, dass Subnetze zu langsam aktualisiert werden.
Eine normale Leistungsbewertung würde die Operation "Update Subnetwork" für alle Subnetze im System mit einem einzelnen Prozess ausführen, um ein Diagramm zu erstellen, das die Antwortzeiten dieses Servers zeigt. Dies erzeugt ein Diagramm wie das folgende:
Obwohl es interessant ist, die Verteilung der Antwortzeiten zu sehen, liefert es keine Erkenntnisse darüber, warum einige Antworten besser sind als andere oder was weiter untersucht werden muss. Stattdessen behandelt dieser Ansatz jede Antwort als gleichwertig – was im Fall von Subnetzen nicht zutrifft. Durch das Parsen der Protokolldateien können Sie Diagramme erstellen, die aussagekräftigere Einblicke bieten.
Eine einfache Möglichkeit zur Identifizierung problematischer Subnetze zur Überprüfung besteht darin, ein Diagramm zu erstellen, das den Namen des Subnetzes aus den Protokollen zusammen mit seiner Antwortzeit enthält.
Dies ermöglicht es Ihnen, ein bestimmtes Subnetz in den Daten zur Untersuchung zu finden und gleichzeitig einen Eindruck davon zu bekommen, wie sich das Gesamtsystem verhält. So lassen sich Ihre am besten und am schlechtesten performenden Subnetze sowie Ausreißer leichter identifizieren.
Mit etwas mehr Aufwand können Sie auch die Anzahl der Features in jedem Subnetz aus den Protokolldateien parsen. Dadurch können Sie ein Diagramm erstellen, das die Anzahl der Features in jedem Subnetz auf der X-Achse verwendet.
Dieses Diagramm erleichtert es zu erkennen, wie Netzwerkgröße und Antwortzeit korrelieren. Es zeigt Ihnen, dass meistens die größeren Subnetze länger für Updates benötigen. Außerdem sehen Sie einige kleinere Netzwerke, die länger als erwartet brauchen – so können Sie Ihre Aufmerksamkeit gezielt darauf richten.
Sie können diesen Ansatz noch weiterführen und detailliertere Informationen aus den Protokollen parsen, um die Zeitpunkte bestimmter Operationen innerhalb jedes Subnetzes zu sehen.
Dieses Diagramm zeigt Ihnen die Operationen und Subnetze mit dem größten Zeitaufwand. Diese detaillierten Informationen ermöglichen es Ihnen zu untersuchen, welche Schritte unternommen werden können, um die Dauer dieser spezifischen Operationen zu verbessern.
In diesem Artikel lernen Sie einige wichtige Überlegungen kennen, die bei der Interpretation der Zeiten für folgende Protokolle gemacht werden sollten:
- Tracing verwendet das TraceLog
- Update Subnetwork verwendet das UpdateSubnetworkLog
- Export Subnetwork verwendet das ExportSubnetworkLog
- Enable Network Topology und Validate Network Topology verwenden das BuildLog
Bevor wir über die einzelnen Protokolle sprechen: Lassen Sie uns über die Bedeutung sprechen, diese Werkzeuge zur Isolierung und Fehlerbehebung von Leistungsproblemen einzusetzen.
Leistung isolieren
Bei der Fehlerbehebung eines Leistungsproblems in ArcGIS Enterprise kann dieses durch eine Vielzahl von Architektur-, Konfigurations- oder sogar Datenproblemen verursacht werden. Wenn sich das Problem auf die Leistung einer einzelnen Operation im utility network konzentriert und keine Versionierung erfordert, ist eine gute Methode zur Reduzierung der Abhängigkeiten und Isolierung des Problems zunächst eine Kopie des utility network in eine neue mobile Geodatabase anzulegen.
Durch die Arbeit mit einer lokalen mobilen Geodatabase können Sie sich auf die Leistung des utility network selbst konzentrieren ohne zusätzliche Variablen durch die Architektur der ArcGIS Enterprise-Bereitstellung. So fokussieren Sie einen Single-User-Workflow ohne Versionierung.
Die Leistung des utility network in einer lokalen Umgebung entspricht nicht der in einer Enterprise-Umgebung. Dennoch ermöglicht dies festzustellen, ob ein Leistungsproblem durch Daten und Konfiguration des utility network oder durch Architektur und Konfiguration der Umgebung verursacht wird.
Wenn sich das Leistungsproblem in der lokalen Umgebung nicht reproduzieren lässt, können Sie dennoch Informationen aus lokalen Tests nutzen um Ihre Untersuchung in Enterprise zu unterstützen. Vergleichen Sie Zeiten und Schritte der detaillierten Protokolle zwischen lokaler Geodatabase und Enterprise-Geodatabase um festzustellen ob einzelne Schritte länger dauern. Dies könnte auf ein Datenbankproblem hinweisen welches Sie durch Auswertung von Performance-Plänen mit verfügbaren DBMS-Werkzeugen vertiefen können.
Sie können auch die Zeit jeder Operation aus den ArcGIS Server-Protokollen mit den vom Client gemeldeten Antwortzeiten vergleichen. Große Abweichungen oder inkonsistente Antwortzeiten könnten auf Kommunikationsprobleme zwischen Client und Server hindeuten. Die folgenden Grafiken zeigen welche Zeiten von verschiedenen Protokollen erfasst werden.
Die Messung der Client-Antwortzeit umfasst die Gesamtzeit für den Abschluss der Anfrage auf Anwendungsebene sowie Server- und Datenebene der Architektur. Dies ist oft wenig hilfreich zur Identifikation der Ursache eines Leistungsproblems bleibt aber wichtig für ein vollständiges Verständnis des Kontexts und Workflows zur Reproduktion des Problems.
Die ArcGIS Server-Protokolle erlauben es Ihnen sich auf Zeiten im Server- und Datenbereich zu konzentrieren während sie zusätzlich Kontext für jede Anfrage neben deren Dauer liefern.
Die Überprüfung der Leistung auf Datenbankebene liefert ebenfalls nützliche Einblicke bei leistungsbezogenen Problemen insbesondere wenn diese datenbankbezogen sind bietet jedoch keinen Kontext zum Client- oder Anwendungsteil.
Das Kopieren von Daten in eine lokale mobile Geodatabase sowie das Erfassen von Protokollen mittels Diagnostic Monitor in ArcGIS Pro ist eine effektive Methode zur Isolierung von Leistungsproblemen. Dies ermöglicht Kontrolle über Workflow und Kontext jeder Operation bei möglichst wenigen Abhängigkeiten sowie Messung ihrer Leistung. Unten sehen Sie eine Darstellung dieses Szenarios.
Jetzt wo Sie verstehen wie und warum man Leistungsprobleme bei Tests isolieren möchte schauen wir uns an wie man utility network-Protokolle analysiert um Leistungsinformationen zu erhalten.
Trace Log
Das Trace Log hat vier wichtige Abschnitte:
- Umgebung
- Trace-Parameter
- Schritte und Zeiten
- Netzwerkindexstatistiken
Bei der Bewertung der Gesamtleistung eines Systems betrachtet man häufig die Gesamtzeit jeder Trace im Vergleich zur Anzahl zurückgegebener Elemente. Das häufigste Testszenario hierfür ist einen Subnetztrace für jedes Subnetz im utility network durchzuführen und dann die Laufzeit des Traces gegen Anzahl Elemente pro Subnetz zu messen.
Der Trace desselben Subnetzes liefert unterschiedliche Leistungswerte je nachdem ob es sich um einen benutzerkonfigurierten Trace handelt oder den Trace welcher bei Export Subnetwork bzw. Update Subnetwork verwendet wird. Bei Messung der Trace-Leistung sollten Sie sich auf Performance von Subnetztraces mit Ihrer Standardkonfiguration während Update Subnetwork konzentrieren. Planen Sie Export Subnetwork einzusetzen sollten Sie auch Performance von Trace während Export Subnetwork mit erwarteter Konfiguration messen.
Wenn ein bestimmtes Subnetz unterdurchschnittlich performt können Sie anschließend Zeiten einzelner Schritte pro Subnetz im Vergleich zur Anzahl Elemente betrachten.
Wenn Sie sich die verschiedenen Schritte einer Trace-Operation ansehen, werden Sie verstehen, warum bestimmte Traces länger dauern und welchen erheblichen Einfluss die Konfiguration eines Traces auf die Gesamtleistung hat.
Zum Beispiel können Sie mit einem solchen Diagramm die Leistung eines Traces analysieren, nachdem Funktionen oder bestimmte Ergebnistypen hinzugefügt wurden. So können Sie die Leistungskosten dieser spezifischen Änderungen messen, wobei jede als eigene Operation mit zugehörigen Kosten dargestellt wird.
Umgebung und Trace-Parameter
Der Konfigurationsabschnitt hilft Ihnen, den Kontext des Traces zu verstehen. Er zeigt den Trace-Typ, die Version, die Startpunkte und die Trace-Konfiguration sowie die für den Trace angegebenen Ergebnistypen an. All diese Parameter beeinflussen das Verhalten des Traces. Eine Änderung an einem dieser Parameter würde ein anderes Ergebnis liefern und könnte die Leistung beeinflussen.
Schritte und Zeiten
Dieser Abschnitt des Protokolls enthält detaillierte Informationen über alle während des Traces durchgeführten Operationen und deren Dauer. Einige Schritte enthalten auch Informationen darüber, wie viele Features in diesem Schritt des Traces beteiligt waren.
Bei der Analyse der Zeit sollten Sie zuerst betrachten, wie lange der gesamte Trace gedauert hat, und dann die Größe der Ergebnisse betrachten. Die Anzahl der durchlaufenen und zurückgegebenen Elemente finden Sie am Ende von Schritte und Zeiten in den folgenden Zeilen:
Die Gesamttracezeit ist leicht zu verstehen; sie ist die gesamte Zeit, die für die Durchführung des Traces benötigt wurde. Die Anzahl der entdeckten Elemente erfordert etwas mehr Überlegung, da sie sowohl die Anzahl der durchlaufenen Elemente als auch die Anzahl der Elemente im Ergebnis umfasst.
Das ist wichtig, da viele Traces viele Elemente durchlaufen, aber nur eine Teilmenge der Ergebnisse zurückgeben. Auch wenn nur wenige Features zurückgegeben werden, kann der Trace viele Features analysieren müssen. Beispiele hierfür sind Upstream- oder Downstream-Traces, Traces mit konfiguriertem Filterbarriere oder Traces, die während des Update Subnetwork ausgeführt werden, um Features in mehreren Subnetzen zu entdecken. Deshalb sind durchlaufene Elemente oft ein besserer Leistungsindikator als die Ergebnisgröße.
Sie sollten auch die einzelnen Schritte und deren Zeiten während des Traces überprüfen. Diese Details zeigen Ihnen, wo während des Traces Zeit verbracht wird.
Netzwerkindexstatistiken
Die Netzwerkindexstatistiken zeigen Ihnen, wie viele Netzwerkinformationen während der Analyse aus der Datenbank geladen wurden. Diese Protokolle werden typischerweise nur von Support und Entwicklung zur Diagnose spezifischer Probleme verwendet.
Dieser Abschnitt enthält folgende Statistiken:
- Topologietabellenstatistiken – Eine Zusammenfassung darüber, wie viele Zeilen aus der Netzwerktopologie gelesen wurden.
- Assoziationstabellenstatistiken – Eine Zusammenfassung darüber, wie viele Assoziationen gelesen wurden.
- Weight Engine-Statistiken – Eine Zusammenfassung darüber, wie viele Netzwerkattribute gelesen wurden.
- Speichermanager-Statistiken – Eine Zusammenfassung über den verwendeten Speicher.
Wenn Sie sich entscheiden, in diesen Bericht einzutauchen, werden Sie feststellen, dass nicht alle Netzwerkattribute im Abschnitt Weight Engine-Statistiken aufgeführt sind. Das liegt daran, dass netzwerkattribute inline gespeichert in den Topologietabellen gespeichert sind und beim Zugriff auf die Konnektivität für das Feature aus der Datenbank einbezogen werden. Jedes außerhalb gespeicherte Netzwerkattribut (out-of-line) aus dem Netzwerkindex verursacht geringe Kosten, meist nicht mehr als einige Millisekunden bei kleinen Netzwerken. Wenn jedoch viele out-of-line Netzwerkattribute gelesen werden oder das Netzwerk viel größer ist, können diese Kosten spürbar werden.
Deshalb sollten Sie erwägen, die für die meisten Ihrer Traces benötigten Netzwerkattribute inline zu speichern, insbesondere jene, auf die Ihre Subnetzdefinition verweist. Warum sind nicht alle Netzwerkattribute inline gespeichert? Weil nur begrenzter Speicherplatz für inline gespeicherte Netzwerkattribute verfügbar ist. Daher müssen Sie entscheiden, welche Attribute am wichtigsten sind und sicherstellen, dass diese inline gespeichert werden. Außerdem erscheinen inline gespeicherte Netzwerkattribute nicht in den Netzwerkindexstatistiken.
Beim Vergleich von Ergebnissen zwischen zwei Tests können Sie auch Cache-Misses betrachten, um festzustellen, wie viel im Speicher (im Cache) verfügbar war im Vergleich zu den aus der Datenbank gelesenen Zeilen.
Beim Vergleich der Leistung verschiedener Traces oder Operationen ist es wichtig auf die Anzahl der Cache-Misses zu achten. Ein Trace, der vollständig aus dem Speicher (hot cache) ausgeführt wird, läuft schneller als derselbe Trace, bei dem Konnektivitätsinformationen aus der Datenbank geladen werden müssen (cold cache).
Im Benutzerworkflow können Sie dies kaum steuern, aber es ist wichtig bei der Einrichtung einer konsistenten Testmethode zu berücksichtigen, damit Sie Ergebnisse verschiedener Tests genau vergleichen können. Die konservativste und konsistenteste Methode zur Messung ist sicherzustellen, dass alle Tests gegen einen cold cache durchgeführt werden.
Update Subnetwork-Protokoll
Bei der Bewertung der Leistung von Update Subnetwork sollten Sie mit dem Update Subnetwork-Protokoll beginnen, das während des Update Subnetwork-Vorgangs erstellt wurde. Außerdem möchten Sie oft das Trace-Protokoll jedes Subnetzes überprüfen, da dies oft den größten Teil der Zeit beim Aktualisieren eines Subnetzes ausmacht.
Hinweis: Beim Überprüfen des Trace-Protokolls für Update Subnetwork werden Sie feststellen, dass Schritte und Zeiten anders sind als bei einem normalen Trace. Das hängt von Ihrer Netzwerkkonfiguration ab; Sie sehen mehr Zeitaufwand beim Finden von Elementen in mehreren Subnetzen (bei Netzwerken mit Propagation), Zeit zum Abrufen von Geometrien zur Berechnung der Subnetzlinie sowie Zeit zum Berechnen von Funktionen für die aggregierte Linie.
Wie beim Trace-Protokoll gibt es drei Abschnitte im Update Subnetwork-Protokoll.
- Umgebung
- Subnetzparameter
- Schritte und Zeiten
- Netzwerkindexstatistiken
Bei der Bewertung der Leistung von Update Subnetwork berücksichtigen Sie folgende Informationen:
- Wie lange dauerte das Aktualisieren des Subnetzes?
- Wie groß war das aktualisierte Subnetz?
- Wie viele Features wurden aktualisiert?
Die ersten beiden Informationen finden sich leicht im Protokoll; für die letzte müssen Sie das Protokoll lesen, um herauszufinden, wie viele Features geändert wurden.
Bei der Bewertung der Gesamtleistung des Systems betrachten Sie typischerweise die Zeitdauer für das Aktualisieren jedes Subnetzes im System im Verhältnis zur Anzahl der Features im Subnetz.
Bei dieser Analyse können Sie drei verschiedene Szenarien betrachten:
- Wie lange dauert es, den ersten Update Subnetwork-Vorgang durchzuführen?
- Wie lange dauert es ein Subnetz zu aktualisieren, wenn sich nichts geändert hat?
- Wie lange dauert es ein Subnetz zu aktualisieren, wenn eine angemessene Anzahl von Features geändert wurde?
Sie konzentrieren sich typischerweise darauf, wie viel Zeit benötigt wird um Update Subnetwork bei einer angemessenen Anzahl von Änderungen auszuführen – denn das entspricht dem Nutzererlebnis im Alltag. Der erste Update Subnetwork-Durchlauf ist wichtig zu beachten, da er am zeitaufwändigsten ist und bei Systembereitstellung durchgeführt werden muss. Das Szenario ohne Änderungen ist interessant als Best-Case-Szenario für Leistung.
Wenn Sie ein unterperformantes Subnetz finden, können Sie anhand der Zeiten einzelner Schritte feststellen, ob ein bestimmter Schritt den Großteil der Zeit beansprucht.
Wenn Sie die Zeit vergleichen, die ein Trace während eines Update Subnetwork-Vorgangs benötigt im Vergleich zu einem normalen Subnetz-Trace, stellen Sie meist fest, dass der Trace während Update Subnetwork länger dauert. Das liegt daran, dass Update Subnetwork zusätzliche Arbeit leistet: Geometrien laden zum Aggregieren, Zusammenfassungsfunktionen berechnen und in manchen Fällen Elemente in mehreren Subnetzen finden.
Umgebung und Subnetzparameter
Beim Überprüfen des Konfigurationsabschnitts sollten Sie besonders auf folgende Einstellungen achten:
- Versionsname
- Bearbeitungsmodus
- Tier-Name
Der Versionsname und Bearbeitungsmodus sind wichtig, da sich Verhalten und Dauer des Update Subnetwork je nach verwendetem Bearbeitungsmodus sowie ob es in default oder einer benannten Version stattfand unterscheiden können. Mehr dazu erfahren Sie im Verstehen von Subnetzen: Bearbeitungsmodus Artikel. Kurz gesagt: Wenn der Bearbeitungsmodus auf ‚mit Ereignissen‘ gesetzt ist entstehen zusätzliche Leistungskosten durch Attributregeln; wenn er ‚ohne Ereignisse‘ in einer benannten Version ist kann es sein dass nicht alle Features im Subnetz aktualisiert werden.
Es ist auch wichtig den Tier-Namen bei Leistungsbetrachtungen zu berücksichtigen; denn die Trace-Konfiguration des Tiers steuert das Verhalten von Update Subnetwork bezüglich Erstellung oder Aktualisierung einer Subnetzlinie sowie Netzdiagrammen usw.
Schritte und Zeiten
Bei Betrachtung von Schritten und Zeiten interessieren vor allem folgende Abschnitte:
- Trace
- Die verschiedenen Update-Schritte (Konnektivität, Inhalt usw.)
- Verwaltung der Subnetzlinie
- Verwaltung der Netzdiagramme
- Gesamt
Sie sehen sich den Trace an um zu sehen wie viel Zeit dieser benötigt hat und vor allem wie viele Features als Teil des Subnetzes entdeckt wurden.
Anschließend betrachten Sie wie viel Zeit für das Aktualisieren verschiedener Attribute in der Datenbank aufgewendet wurde welche persistente Informationen zum Subnetz verfolgen (Subnetzname, verbunden oder nicht usw.).
Die Zeit für Verwaltung der Subnetzlinie und Netzdiagramme ist normalerweise relativ gering. Wenn diese jedoch signifikant viel Zeit beanspruchen sollten Sie deren Konfiguration überprüfen.
Die Gesamtzeile zeigt Ihnen die gesamte Zeit an welche für das Aktualisieren des Subnetzes benötigt wurde.
Netzwerkindexstatistiken
Die Überlegungen zur Überprüfung der Netzwerkindexstatistiken bei Update Subnetwork sind dieselben wie beim Trace-Protokoll.
Exportprotokoll
Bei Bewertung der Leistung von Export Subnetwork berücksichtigen Sie drei Dinge:
- Welche Ergebnistypen, Attribute usw. wurden exportiert?
- Wie lange dauerte es alle vom Trace angeforderten Informationen zum Export abzurufen?
- Wie lange dauerte es die Datei zu erzeugen?
Um diese Fragen zu beantworten, schauen Sie hauptsächlich in das Exportprotokoll. Es wird ein TraceLog für den Trace erstellt, der als Teil des Export-Subnetzwerkvorgangs ausgeführt wird, falls Sie eine detailliertere Aufschlüsselung der während dieses Vorgangs verbrachten Zeit benötigen.
Im Exportprotokoll gibt es fünf verschiedene Abschnitte:
- Umgebung
- Subnetzwerkparameter
- Exportparameter
- Schritte und deren Zeiten
- Netzwerkindexstatistiken
Bei der Bewertung der Gesamtleistung des Export-Subnetzwerks möchten Sie die benötigte Zeit für den Export-Subnetzwerkvorgang mit der Anzahl der exportierten Features vergleichen. Im Gegensatz zu TraceLog und UpdateSubnetworkLog enthält es jedoch keine Zählung, wie viele Features durch den Trace zurückgegeben wurden.
Die Anzahl der Features kann jedoch aus dem TraceLog extrahiert werden.
Wenn Sie feststellen, dass ein Subnetzwerk während des Exportvorgangs unterdurchschnittlich arbeitet, sollten Sie im Exportprotokoll nachsehen, wo die Zeit verbracht wird. Wenn die meiste Zeit im Trace verbracht wird, sollten Sie das TraceLog überprüfen. Dabei ist es oft hilfreich, dies mit der während eines normalen Subnetzwerk-Traces (ohne Ergebnisarten oder Funktionen) verbrachten Zeit zu vergleichen.
Dieser Ansatz ermöglicht es Ihnen zu erkennen, wie viel Zeit während des Traces im Export-Subnetzwerk für jede Ergebnisart (Konnektivität, Feature-Elemente usw.) aufgewendet wird und wie viel Zeit für die Ausführung des Traces benötigt wird. Der Trace während des Exports dauert immer länger als ein regulärer Trace, da zusätzliche Informationen aus der Datenbank gelesen werden müssen. Die Details des TraceLogs während des Exports zeigen Ihnen, wie viel Zeit für jede Ergebnisart aufgewendet wird.
Deshalb ist es wichtig, nur die Attribute und andere Informationen zu exportieren, die notwendig sind, da das Exportieren unnötiger Informationen hohe Kosten verursachen kann.
Umgebung und Parameter
Export-Subnetzwerk bietet viele Optionen, die steuern, was exportiert werden kann. Je mehr Informationen Sie jedoch in den Export einschließen, desto länger dauert der Trace zur Erfassung aller Informationen. Je mehr Informationen Sie einschließen, desto größer werden die Dateien und desto länger dauert es, sie zu erstellen und herunterzuladen.
Sie können sehen, welche Informationen ein Benutzer in seinen Export aufgenommen hat, indem Sie den Abschnitt Exportparameter im Bericht ansehen. Dort sehen Sie, welche Ergebnisarten enthalten waren sowie wie viele Netzwerkattribute, Ergebnisfelder (für Features) und verwandte Datensatzfelder (für verwandte Datensätze) ausgewählt wurden.
Das Einbeziehen vieler Attribute von Features und verwandten Datensätzen erfordert zusätzliche Abfragen an die Datenbank, was die Dauer des Traces zur Informationsbeschaffung verlängern kann. Außerdem kann das Auswählen vieler Attribute die Dateigröße drastisch erhöhen. Das Einbeziehen aller Netzwerkattribute für ein Subnetzwerk kann die Dateigröße verdoppeln und die Dauer des Exports verlängern. Das Einbeziehen von Attributen aus vielen verschiedenen Tabellen wirkt sich noch stärker negativ auf die Leistung aus.
Schritte und Zeiten
Im Export-Subnetzwerkprotokoll gibt es weniger Schritte zu analysieren. In den meisten Fällen ist der Trace der kostenintensivste Schritt beim Export-Subnetzwerk. Wenn jedoch viel Zeit bei den Schritten Prozess/JSON schreiben verbracht wird, deutet dies darauf hin, dass die Datei groß ist und das Serialisieren, Herunterladen und Speichern lange dauert.
Netzwerkindexstatistiken
Die Überlegungen zur Überprüfung der Netzwerkindexstatistiken für das Export-Subnetzwerk sind dieselben wie beim TraceLog.
Build-Protokoll
Das Format des Build-Protokolls unterscheidet sich von den anderen Utility Network-Diagnoseprotokollen, da es als inkrementelles Protokoll konzipiert ist, das während potenziell lang andauernder Sitzungen erstellt wird. Daher berichtet jede Zeile im Build-Protokoll über die für den Schritt benötigte Zeit, die bis dahin insgesamt verstrichene Zeit und den zu diesem Zeitpunkt verwendeten Speicher.
Dasselbe Protokolldateiformat wird für alle drei Build-Vorgänge verwendet:
- Netzwerktopologie aktivieren
- Netzwerktopologie deaktivieren
- Netzwerktopologie validieren
Aus diesem Grund kann es vorkommen, dass in einigen Protokollen bestimmte Schritte übersprungen erscheinen. Das liegt daran, dass nicht alle Schritte für alle Vorgänge gelten.
Beim Überprüfen der Protokolle sollten Sie sich auf folgende Abschnitte konzentrieren
Bei der Leistungsbewertung sollten Sie berücksichtigen, welcher Build-Typ durchgeführt wird, wie viele Netzwerkattribute verarbeitet werden, wie viel verfügbarer Speicher/Festplattenspeicher vorhanden ist, ob Analysen zur Identifizierung von Subnetzwerken durchgeführt wurden (Nachbearbeitung nach dem Aufbau) und wie viele Features verarbeitet werden. Die meisten dieser Informationen finden Sie in den Abschnitten Umgebung und Netzwerkaufbau-Einrichtung im Protokoll.
Bei Netzwerktopologie aktivieren und deaktivieren liegt Ihr Hauptaugenmerk auf Durchsatz, Speichernutzung und Festplattennutzung. Je mehr Sie sich auf Speicher verlassen können, um die Netzwerktopologie aufzubauen, desto schneller geht es; bei großen Datensätzen ist dies jedoch unrealistisch. In solchen Fällen beginnt der Build damit, Informationen auf die Festplatte zu schreiben; dann müssen Sie sicherstellen, dass die konfigurierte Festplatte schnell ist (idealerweise eine SSD) und genügend Speicherplatz für temporäre Dateien vorhanden ist.
Bei Netzwerktopologie validieren liegt Ihr Hauptaugenmerk auf der Gesamtzeit des Builds, da ein Benutzer typischerweise Netzwerktopologie validiert aufruft und Sie die Wartezeit minimieren möchten. Wenn Sie feststellen, dass viel Zeit in der Nachbearbeitung nach dem Aufbau verbracht wird, sollten Sie sich mit dem Artikel zum Verständnis des Status von Subnetzwerken vertraut machen. Dieses Verhalten wird durch die Subnetzwerkdefinition für jede Ebene im Netzwerk gesteuert und kann auch nach Bereitstellung Ihres Utility Networks geändert werden. Utility Networks, die ein Statusfeld für ihre Subnetzwerke pflegen müssen während Netzwerktopologie validieren eine Nachbearbeitung durchführen, um betroffene Subnetzwerke zu finden und als "dirty" zu markieren.
Umgebung und Netzwerkaufbau-Einrichtung
Der geprüfte Bereich wird im Umgebungsabschnitt des Build-Protokolls angezeigt; dieser Bereich ist nur bei der Bewertung von Netzwerktopologie validieren relevant. Denn Netzwerktopologie aktivieren und deaktivieren laufen immer über den gesamten Bereich des Netzwerks.
Die Schritte zum Aufbau des Netzwerks sowie der Name der Protokolldatei zeigen den durchgeführten Build-Typ an. Außerdem sehen Sie, wie viele Netzwerkattribute sowie Speicher- und Festplattenspeicher beim Start verfügbar waren. Wenn der während des Builds verwendete Speicher den verfügbaren Speicher überschreitet, beginnt der Prozess mit dem Schreiben auf die Festplatte und wird langsamer.
Schritte und deren Zeiten
Es gibt viele Schritte im Netzwerkaufbauprozess; obwohl hier nicht alle beschrieben sind, sollten Sie beim Überprüfen der Protokolle Folgendes beachten:
- Wie viele Informationen wurden in diesem Schritt verarbeitet?
- Wie viele Informationen wurden in diesem Schritt erstellt?
- Wie viel Zeit/Speicher hat dieser Schritt verwendet?
Jeder Schritt berichtet normalerweise in seiner letzten Nachricht über die gesamte benötigte Zeit zur Fertigstellung.
Die Gesamtzeit des gesamten Vorgangs finden Sie in der letzten Zeile der Protokolldatei.
Um den verwendeten Speicher zu ermitteln, müssen Sie den gemeldeten Gesamtspeicher in der ersten Lognachricht mit dem in der letzten Lognachricht desselben Schritts vergleichen.
Netzwerkindexstatistiken
Da der Netzwerkaufbauprozess den Netzwerkindex füllt, kann dieser Abschnitt interessant sein um zu verstehen wie viele Informationen von Systemtabellen gelesen, geschrieben oder erstellt wurden. Allerdings können Sie diese Zahlen kaum beeinflussen sobald ein Utility Network bereitgestellt wurde.
Wenn Sie sich noch am Anfang eines Projekts befinden, können Sie sehen wie sich die Anzahl Ihrer Netzwerkattribute auswirkt und diese Gelegenheit nutzen um sicherzustellen dass alle benötigten Netzwerkattribute im Modell enthalten sind. Wenn Sie keine Netzwerkattribute für Workflows benötigen und noch am Anfang stehen sowie diese aus Ihrem Modell entfernen können sollten Sie dies erwägen. Ein Netzwerkattribut kann jederzeit hinzugefügt werden; nach Bereitstellung kann es jedoch nicht entfernt werden.
Wenn Sie überlegen ob verwandte Datensätze weiterhin als solche modelliert oder als nicht-räumliche Objekte mit Konnektivität bzw. Containment modelliert werden sollen sehen Sie hier auch wie lange es dauert das Netzwerk aufzubauen um diese zusätzlichen nicht-räumlichen Objekte einzubeziehen.
Fazit
Nachdem Sie diesen Artikel gelesen haben sollten Sie mit der Interpretation der Protokolle für die vier Hauptoperationen des Utility Networks vertraut sein. Sie können beginnen Leistungstests durchzuführen und Ergebnisse detailliert auszuwerten. Während Sie Ihre Architektur entwerfen und wichtige Entscheidungen zur Datenmodellierung treffen können Sie so deren Auswirkungen auf Ihre Leistung messen.
Für einen systematischeren Ansatz zur Erfassung und Messung von Leistungsdaten möchten Sie möglicherweise ein Tool wie Extract Log Files verwenden um Protokolle in einer Datenbank zusammenzuführen. Die Grafiken in diesem Artikel wurden mit einem Ansatz erstellt bei dem Leistungszahlen aus jeder Protokolldatei mittels regulärem Ausdruck extrahiert wurden um Visualisierungen zu erstellen.
Diese Protokolldateien sind wichtig weil sie eine präzise Messung darüber liefern wie viel Zeit der Server mit bestimmten Operationen verbringt. Sie sind äußerst wertvoll zur Bewertung einzelner Vorgänge; bieten jedoch kein vollständiges Bild. Leistungsanalysen müssen ganzheitlich erfolgen um nicht nur die Leistung des Utility Networks sondern auch den Einfluss der gesamten Architektur sowie das Verhalten unter Last zu berücksichtigen.
Für Beispiele eines ganzheitlicheren Ansatzes bei Tests und Design besuchen Sie das ArcGIS Architecture Center.
Für Beispiele dazu wie das Modellieren verwandter Datensätze Leistung beeinflussen kann verweisen wir auf den Artikel zum Modellieren verwandter Daten in einem Utility Network.
Beispiele dafür, wie die Konfiguration des Editiermodus Ihres Subnetzes die Leistung beim Aktualisieren des Subnetzes beeinflussen kann, finden Sie im Understanding Subnetwork Edit Mode Artikel.
Beispiele dafür, wie die Konfiguration der Statusverwaltung Ihres Subnetzes die Leistung bei der Validierung der Netzwerktopologie beeinflussen kann, finden Sie im Understanding Subnetwork Status Artikel.
