Optimieren der Performance in ArcGIS

Um ein ähnliches Performance-Niveau für Benutzer zu erzielen, die auf einen Service zugreifen, ist es wichtig, zu verstehen, dass es je nach Typ des räumlichen Service unterschiedliche Optimierungsmethoden gibt. Welche Optionen verfügbar sind, hängt davon ab, um welche Backend-Datenquelle es sich handelt oder welches Softwarebereitstellungsmuster verwendet wird. Das Verständnis der verschiedenen Arten von Caching und Kachelung sowie anderer Formen der Optimierung ist ein wichtiger Bestandteil beim Gewährleisten einer positiven User Experience. In diesem Abschnitt wird kurz eine Vielzahl von Techniken zur Performance-Optimierung auf verschiedenen Ebenen der ArcGIS-Architektur behandelt.

Netzwerkdesign für Performance

Das Design des Netzwerks, in dem ArcGIS-Komponenten bereitgestellt werden, trägt wesentlich zur Performance bei (sowohl zu einer guten als auch zu einer schlechten Performance). Unternehmenssysteme sind häufig globaler Natur und werden von Benutzern über eine Vielzahl von Netzwerkbedingungen und -verbindungen hinweg verwendet. Außerdem bestehen wichtige Unterschiede zwischen ArcGIS-Komponenten und -Workflows in Bezug auf ihre Abhängigkeit von der Netzwerkverbindung. Der Umfang der Netzwerküberlegungen für ArcGIS-Workflows geht über dieses Thema hinaus, aber einige erste Empfehlungen und Überlegungen umfassen die folgenden:

  • Im Allgemeinen wirkt sich die Netzwerklatenz für den täglichen GIS-Betrieb stärker auf die User Experience aus als die Netzwerkbandbreite. Für Aktivitäten wie das Herunterladen von Daten, das Kopieren von Dateien oder das Anzeigen großer Bilddaten-Datasets ist die Bandbreite ebenfalls wichtig.
  • Der Datenverkehr von ArcGIS Pro direkt zu Datenbanken ist latenzempfindlich, und beim Anzeigen und Bearbeiten von Daten sowie beim Arbeiten mit und Ändern von Schemas werden viele kleine Aufrufe getätigt.
  • Der Datenverkehr von ArcGIS Server zu Datenbanken, Datei- oder Objektspeichern erfordert ebenfalls eine geringe Latenz und im Allgemeinen eine hohe Bandbreite. Auf diese Weise kann der Serverprozess auf die Daten zugreifen, sie so transformieren, dass sie den Benutzeranforderungen entsprechen, und eine optimierte Antwort an die Benutzer zurücksenden.
  • Clients, wie z. B. Browser, die auf Webanwendungen zugreifen, reagieren weniger empfindlich auf Netzwerkeinschränkungen als Desktop-Clients, da Maps SDK for JavaScript Anforderungen optimiert, um übermäßigen Datenverkehr zu reduzieren.
  • Viele moderne Netzwerke verwischen die Unterscheidung zwischen lokalen Ressourcen und Cloud-Ressourcen durch Netzwerk-Peering und andere Technologien, was zu einer sehr geringen Latenz zwischen Cloud-Ressourcen und lokalen Ressourcen oder Clients führen kann. Generell wird empfohlen, Clients, Serverprozesse, Speicher und Datenbanken in der gleichen “Netzwerkzone” zu hosten. Dies bedeutet zum Beispiel, dass alle in der Cloud oder alle lokal gehostet werden, aber in einigen Szenarios ist es akzeptabel, dass Clients von Servern oder Server von Datenbanken getrennt werden. Wie geeignet dieses Design für Ihr System ist, hängt von Ihrem Netzwerkdesign und von strukturierten Tests der Auswirkungen ab.

Optimieren von Web-Apps

Webanwendungen werden von einem Webserver bereitgestellt, bei dem es sich häufig um einen ArcGIS Online SaaS-Service, einen Webserver, der einen ArcGIS-Web Adaptor hostet, oder einen Webserver handelt, der für das Hosten benutzerdefinierter Webanwendungen vorgesehen ist. Nachfolgend werden Methoden zum Hosten optimierter Webanwendungen beschrieben.

Erstellungsprozess

Vor dem Bereitstellen einer Anwendung kann ein Erstellungsprozess (auch als Minifizierung oder Bündelung bezeichnet) verwendet werden, um die Größe und Komplexität der statischen Ressourcen der Anwendung, z. B. JavaScript-, CSS- und HTML-Dateien, zu reduzieren oder nicht benötigte Informationen aus diesen Dateien zu entfernen. Es gibt zwar viele gültige Ansätze zum Festlegen eines erfolgreichen und geeigneten Erstellungsprozesses, aber diese Prozesse sind oft eng mit der Anwendungsumgebung verknüpft, die zum Erstellen der Webanwendung verwendet wird.

HTTP-Antwort-Caching

Eine weitere Methode zur Optimierung der Performance von Webanwendungen besteht darin, HTTP-Antwort-Caching für die statischen Ressourcen der Webanwendung zu aktivieren. In dieser Konfiguration erhält der End-Client vom Webserver einen Antwort-Header, der angibt, dass die statische Ressource im Client gecacht werden kann und wie lange sie gecacht werden kann. Auf diese Weise kann der Client-Browser eine vollständige Roundtrip-Anforderung beim erneuten Laden der Anwendung vermeiden, da der Inhalt dieser Datei bereits lokal auf dem Client-Computer gespeichert ist und bis zum Cache-Ablauf unverändert wiederverwendet wird. HTTP-Antwort-Caching kann selektiv für bestimmte Dateitypen aktiviert werden, entweder über einen Webserver oder einen anderen Reverseproxy oder eine Anwendungsbeschleunigungs-Softwareschicht.

Content Delivery Network (CDN)

In ArcGIS Online gehostete Webanwendungen nutzen diese beiden Optimierungsmuster bereits, da sie vor der Bereitstellung erstellt und in einer SaaS-Umgebung gehostet werden, in der CDN-Caching (Content Delivery Network) für statische App-Antworten verwendet wird.

CDNs können auch mit ArcGIS Enterprise verwendet werden. Achten Sie jedoch darauf, zwischen statischen Ressourcen, die für das Caching in einem CDN geeignet sind, wie z. B. HTML-, CSS- und JavaScript-Dateien, und dynamischen REST-API-Antworten zu unterscheiden, die nicht gecacht werden sollten, um unerwartetes Benutzerverhalten zu vermeiden. Seien Sie auch bei der Verwendung eines CDN besonders vorsichtig in Bezug auf Upgrades, da der CDN-Cache zwangsweise ungültig gemacht werden sollte, wenn ein Software-Upgrade durchgeführt wird oder eine Anwendung geändert wird. Dadurch wird sichergestellt, dass Benutzer keine veralteten Informationen erhalten.

Optimieren von Web-Services

Es gibt viele verschiedene Arten von Web-Services, die in einer ArcGIS-Umgebung verwendet werden können. Einige von ihnen werden basierend auf dynamischen Datenquellen angezeigt oder reagieren basierend auf diesen. Es gibt keinen einheitlichen Ansatz für das Caching und die Optimierung dieser Services, sondern eine Vielzahl von Mustern, die mit Bedacht und Planung verwendet werden sollten. Zu den gängigen Methoden zur Optimierung von Web-Services gehören:

  • Raster-Kachel-Caches
  • Vektorkachel-Caches

Bei beiden Methoden werden Eingabedaten (aus beliebigen Quellen), auf die andernfalls dynamisch über eine Karte, ein Feature oder einen Image-Service zugegriffen werden könnte, in Kacheln gecacht. Bei diesen Kacheln handelt es sich um vordefinierte Datenpakete, die in einem standardmäßigen Raster mit mehreren Ebenen organisiert sind. Gecachte Kacheln ermöglichen es Clients, mehrere vordefinierte Kacheln gleichzeitig für einen bestimmten Maßstab anzufordern. Diese werden in Kachelform “vorab gerendert”, sodass keine Anforderung an die Backend-Daten und keine dynamische Darstellung von Symbolisierung oder Features erfolgt.

  • Raster-Kachel-Caching bezieht sich auf Daten, die in Raster-Kacheln gecacht werden. Bei diesen Kacheln handelt es sich um Bilder, die eine vorab gerenderte Ansicht der Daten anzeigen, die dann auf dem Client als ein Satz mehrerer zusammengefügter Kacheln für jede Anzeigeausdehnung dargestellt werden. Raster-Kacheln können aus Kartenservices, gehosteten Feature-Services oder Image-Services erstellt werden, wobei für die einzelnen Kacheln leicht unterschiedliche Überlegungen gelten.
  • Das Konzept des Vektorkachel-Caching ist ähnlich, aber die Kacheln sind komprimierte Binärdateien (basierend auf Protokollpuffern), in denen Features als Geometrie und Attribute gespeichert werden, die in einzelne Kacheln unterteilt werden, die dann wieder zusammengesetzt und auf dem Client gerendert werden.

Zugehörige Ressourcen:

Strategien für Raster-Kachel-Caching

Raster-Kachel-Caching ist eine effektive Methode, wenn relativ statische Daten bereitgestellt werden, die in einer primären kartografischen Darstellung angezeigt werden sollen. Raster-Kacheln können zwar eine hohe Performance aufweisen, bieten dem Benutzer jedoch nicht die Möglichkeit, Attribute abzufragen, Features zu identifizieren, Symbole zu ändern, die Beschriftung von Layern zu deaktivieren usw.

Während Raster-Kacheln viele Jahre lang zum Bereitstellen kartografischer Grundkarten verwendet wurden, werden bei diesen Services heute aus verschiedenen Gründen der Performance, Kartenqualität und Flexibilität am häufigsten Vektorgrundkarten verwendet. Raster-Kacheln werden nach wie vor verwendet, um viele Bilddaten-Grundkarten oder Services auf der Grundlage von Satelliten- oder Orthofotografien bereitzustellen, da diese Services darauf abzielen, einen einzelnen, sorgfältig ausbalancierten Bilddaten-Layer als Hintergrund für Anwendungen oder Werkzeuge darzustellen.

Strategien für Vektorkachel-Caching

Vektorkachel-Caching ist eine neuere, aber allgemein unterstützte Methode für das Caching von Daten, bei der eine Raster-Kachel möglicherweise einschränkend oder aus anderen Gründen ungeeignet ist. Vektorkacheln können schneller generiert werden und kleiner sein, was Vorteile in Bezug auf die Speicherung des Kachelsatzes sowie auf die Geschwindigkeit hat, mit der die Vektorkacheln über eine Netzwerkverbindung an einen Client übertragen werden.

Vektorkacheln ermöglichen auch dynamisches Rendering durch die Verwendung eines Vektorkachel-Styles, der vollständig im Client, z. B. einem Browser oder einer nativen Anwendung, konfiguriert oder aktualisiert werden kann und verschiedene Layer dynamisch ein- oder ausblenden, basierend auf Attributen filtern und mehrere verschiedene kartografische Versionen derselben Daten anzeigen kann, die alle denselben einzelnen Vektorkachel-Layer verwenden.

Sowohl Raster-Kachel-Caching als auch Vektorkachel-Caching verfügt über eine Vielzahl von Konfigurationen, Optionen und Auswahlentscheidungen, die während der Optimierung eines Service getroffen werden müssen. Weitere Informationen zu diesen Bereichen finden Sie in der zusätzlichen Dokumentation, in den Ressourcen und in den Konferenzberichten von Esri.

Feature-Kacheln

Ein weiterer verwandter Optimierungsansatz ist eine neuere Funktion von ArcGIS, die als Feature-Kacheln bezeichnet wird. Feature-Kacheln werden nicht (wie Vektorkacheln oder Raster-Kacheln) durch einen geplanten Prozess vorab generiert, sondern von funktionalitätsbezogenen Clients generiert, die standardisierte Datenausdehnungen für Standardzoomstufen anfordern. Da diese Anforderungen zwischen verschiedenen Clients identisch sind, können die Features von einem zwischengeschalteten CDN oder Proxy gecacht und wiederverwendet oder erneut an andere Clients gesendet werden. Diese Funktionalität ist ausschließlich für die Verwendung durch Clients verfügbar, die für die Verwendung dieses Features konzipiert sind, hauptsächlich über ArcGIS Maps SDK for JavaScript, aber auch über ArcGIS Pro und native Anwendungen, die mit ArcGIS Maps SDKs erstellt wurden. Die Verwendung von Feature-Kacheln beruht auf mehreren wichtigen Annahmen:

  • Feature-Kacheln werden nur verwendet, wenn Anforderungen an Feature-Layer (basierend auf einem Karten- oder Feature-Service) gesendet werden, die diese Funktion unterstützen, was je nach Version unterschiedlich ist. Diese Funktionalität wird seit mehreren Jahren von ArcGIS Online-basierten gehosteten Feature-Services unterstützt.
  • In der Regel werden Feature-Kacheln automatisch durch die Clients von Services angefordert, die sie unterstützen. ArcGIS Online bietet zwar mehrere Caching-Layer für diese Feature-Kacheln, aber für ArcGIS Enterprise-basierte Layer sind zusätzliche Überlegungen erforderlich, um dieses Feature optimal zu nutzen.
  • Die Objektspeicher-Funktionalität von ArcGIS Data Store ist so konzipiert, dass sie das Caching von Feature-Kacheln unterstützt, sodass Benutzer, die eine Feature-Kachel anfordern, die bereits für eine andere Benutzeranforderung generiert wurde, diese vorhandene Kachel erhalten können. Dadurch wird schnell eine Antwort bereitgestellt, und das Ergebnis wird über einen bestimmten Zeitraum gecacht. Diese Funktionalität erfordert das Aktivieren von Caching für einzelne Layer im gehosteten Feature-Layer mithilfe einer REST-API-Anforderung.

Gehostete Feature-Services in ArcGIS Online enthalten eine Option zum Aktivieren einer optimierten Layer-Darstellung, mit der Daten mit reduzierter Auflösung in der Datenbank generiert werden können und bei kleineren oder stärker verkleinerten Ansichtsmaßstäben verwendet werden. Diese Daten mit reduzierter Auflösung werden bei Verwendung dieser Maßstäbe automatisch vom Feature-Kachel-Generierungsprozess abgefragt, was wiederum die Antwort-Performance verbessert.

Datenquellen und -speicherung

Neben der Anwendungs- und Serviceoptimierung sind die Speicherung und die Eigenschaften der Daten hinter einem bestimmten Service ein ebenso wichtiger Bereich für die Performance-Verbesserung. Die meisten Daten, die in Web-Services verwendet werden, sind tabellarischer Natur (mit Ausnahme von Image-Services) und umfassen in den meisten Fällen die beiden folgenden Elemente:

  • Geometrie: Eine Datenspalte mit dem Datentyp “Geographie” oder “Geometrie”
  • Attribute: Spalten mit anderen unterstützten Datentypen

Sowohl die Geometrie als auch die Attribute können optimiert werden, um eine verbesserte Service-Performance zu unterstützen. Weitere Dokumentation zu diesen Bereichen finden Sie in der ArcGIS Pro-Dokumentation für Einstellungen, die zu Performance-Beeinträchtigungen beim Datenzugriff führen.

Optimieren von Attributen

Sie können die Verwendung von Attributen durch Attributreduzierung optimieren. Vereinfacht ausgedrückt bedeutet dies, dass Spalten oder Attribute, die in einer Tabelle vorhanden sein können, aber für Ihre Anwendung oder Ihren Anwendungsfall nicht benötigt werden, entfernt oder ausgeblendet werden. Dies kann erreicht werden, indem nicht benötigte Spalten entfernt werden, oder indem diese Spalten für die Anzeige in der Karte deaktiviert werden, wenn sie für die Veröffentlichung erstellt wurden, z. B. für Kartenbild-Layer.

Indizieren von Attributen

Die Attributindizierung ist ein weiterer wichtiger Aspekt, vor allem wenn Spalten zum Filtern oder Abfragen in einer Anwendung verwendet werden. Die Indizierung ermöglicht schnellere und effizientere Abfragen, wenn die Anforderungsfilter auf einem bekannten Attribut basieren oder ein Textattribut, ein numerisches Attribut oder ein datumsbasiertes Attribut abgefragt wird. Das Hinzufügen von Attributindizes ist eine hervorragende Möglichkeit, die bereits entwickelte Optimierungstechnologie in relationalen Datenbanken zu nutzen.

Optimieren der Geometrie

Geometriespalten können auch auf mehrere wichtige Arten optimiert werden – je nach Anwendungsfall und Anforderungen an die Daten. Eine Option ist die räumliche Generalisierung, die häufig auch als Vereinfachung bezeichnet wird und bei der die Detaillierungsebene einer geometrischen Darstellung, z. B. einer Linie oder eines Polygons, vereinfacht, geglättet oder reduziert wird, um die Größe des Features und die Speicher- und Verarbeitungsanforderungen zu reduzieren. Dieser Prozess kann dauerhaft durchgeführt werden, wenn die ursprünglichen Daten in Bezug auf die enthaltenen Stützpunkte zu genau oder zu detailliert sind, oder er kann mit einer schreibgeschützten Kopie der Daten durchgeführt werden, die für die Visualisierung verwendet wird, während die Detailtiefe der ursprünglichen Daten vollständig erhalten bleibt.

Eng verwandt ist die Idee der Reduzierung der räumlichen Genauigkeit, die sich auf den geometrischen oder geographischen Datentyp bezieht. Bei diesem wird in der Regel ein Dezimalwert für die tatsächlichen Koordinaten jedes Stützpunktes eines Features gespeichert, z. B. 124999.24541512. Dieser Wert stellt eine lineare Einheit dar, die je nach Koordinatensystem des Dataset variiert, und so groß wie Dezimalgrad oder so klein wie Fuß oder Meter sein kann. In jedem Fall kann es sowohl aus funktionalen Gründen als auch aus Performance-Gründen wichtig sein, sicherzustellen, dass die erfasste räumliche Genauigkeit den tatsächlichen Anwendungsfall der Daten widerspiegelt.

Für Daten in einem Koordinatensystem mit einer meterbasierten linearen Einheit hat eine Geometrie, die als (123456.789101112, 234567.891011121) gespeichert ist, eine Genauigkeit von 9 Dezimalstellen, was der Genauigkeit auf Nanometerebene entspricht. Wenn die Daten von einem GPS-Gerät mit einer Genauigkeit von 1 m (im Durchschnitt) erfasst werden, dann überschätzt diese Genauigkeit die tatsächliche Genauigkeit der Messung um einen signifikanten Faktor. Das Verringern der räumlichen Genauigkeit des Dataset durch Entfernen des Dezimalteils ist nicht nur genauer, sondern es reduziert auch die Größe der Geometrie bei Übertragung in einer Netzwerkanforderung um 50 %, was in vielerlei Hinsicht, von Serialisierungsprozessen bis hin zu Bandbreiteneinschränkungen, hilfreich ist. Die Verwendung einer angemessenen räumlichen Genauigkeit ist besonders wichtig bei sehr detaillierten Polygon-Features, da die Anzahl der Stützpunkte schnell Tausende von Datensätzen erreichen kann und die daraus resultierenden Auswirkungen auf die Service-Performance erheblich sind.

Über Attribut- und Geometrieanpassungen hinaus können auch andere Datenspeicherungsansätze auf höherer Ebene zur Optimierung der Performance beitragen, z. B.:

  • Verwenden Sie Datenbanksichten oder materialisierte Sichten, um eine Abfrage, auf die häufig zugegriffen wird, auf Datenbankebene zu speichern. Die Abfrage kann dann in einem Kartenservice veröffentlicht werden, um sie in ArcGIS-Anwendungen zu verwenden.
  • Überlegen Sie, ob eine File-Geodatabase von einer Komprimierung profitieren kann – dieser Vorgang kann die Performance verbessern, indem der interne Speicher einer häufig bearbeiteten File-Geodatabase neu organisiert wird.
  • Für Enterprise-Geodatabases gilt eine Vielzahl anderer Performance-Überlegungen, von denen einige datenbankspezifisch sein können. Es ist jedoch wichtig, bei Arbeiten mit versionierten Daten die Vorgänge Komprimieren und Datasets analysieren sowie bei Verwendung eines Workflows mit mehreren Editoren eine Vielzahl von Performance-Überlegungen zu berücksichtigen.

Mosaike und Image-Services

Image-Services werden in der Regel aus Mosaik-Datasets erstellt, bei denen es sich um Geodatabase-Objekte handelt, die vielen der oben genannten Optimierungsvorschläge folgen. Darüber hinaus gibt es mehrere Image-Service-spezifische Optimierungstechniken, die in Betracht gezogen werden sollten:

  • Mosaik-Einstellungen, einschließlich der maximalen Anzahl von Rastern pro Mosaik und der maximalen Bildgröße, wirken sich jeweils auf die Service-Performance aus. Durch sie wird sichergestellt, dass das System nicht nach zu vielen Bildern sucht, um das resultierende Mosaik zu erstellen, und dass das resultierende Bild nicht so groß ist, dass das Erstellen und Zurücksenden an den Client den Netzwerkzugriff des Benutzers auf das Mosaik überlastet.
  • Mosaik-Dataset-Übersichten dienen in erster Linie dazu, die Service-Performance in kleineren Maßstäben (stärker verkleinert) zu verbessern. Übersichten stellen vorab gerenderte Ansichten eines Mosaik-Dataset dar, bei dem sich die Daten nicht häufig ändern oder bei dem die Besonderheiten von Bildern in diesem kleinen Maßstab nicht benötigt werden. Das Erstellen von Übersichten und deren Aktualisierung bei Bedarf kann die Darstellungs-Performance des Image-Service für die Benutzer erheblich verbessern.
  • Das Format und die Konfiguration der Quellbilder sind ebenfalls von entscheidender Bedeutung, da es mehr oder weniger optimierte Bildformate gibt, die sich auf die Performance auswirken können, sowie Eigenschaften wie Bildpyramiden, die mit einem Vorabaufwand berechnet werden können, aber allen zukünftigen Benutzern dieses Bildes zugutekommen.
Top