Leistung: Herausforderungen und Strategien
ArcGIS Enterprise bietet eine robuste und skalierbare Plattform zur Bereitstellung von GIS-Ressourcen für Benutzer über Dienste und Webanwendungen. Manchmal kann es jedoch bei Bereitstellungen zu langsamer Leistung der veröffentlichten Ressourcenendpunkte kommen.
Da ArcGIS sehr vielseitig ist, gibt es verschiedene Möglichkeiten, Konfigurationen und Optionen, um diese Ressourcen für die Nutzung verfügbar zu machen.
Eine gute Leistung zu erzielen ist nicht immer so einfach und unkompliziert wie das Umschalten einer Einstellung "fast = true".
Was für einige Administratoren eine praktische Funktion sein könnte, kann eine Konfiguration sein, die zwar hilfreich ist, aber die Leistung für andere beeinträchtigen kann.
In der Praxis ist die Leistung oft eine Funktion mehrerer Elemente und Konfigurationseinstellungen. Strategien zu haben, um die häufigsten Probleme zu verstehen und zu überwinden, kann helfen, die Bereitstellung auf den Weg zu schnellerer Leistung zu bringen.
Was ist Leistung?
Leistung beschreibt, wie schnell (oder langsam) ein Server oder Dienst für eine bestimmte Funktion arbeitet. Wie lange ein ArcGIS Server Dienst benötigt, um eine Operation wie Abfrage, applyEdit oder Export durchzuführen und dann die Antwort an den Client zurückzusenden, der sie angefordert hat, ist ein Beispiel für Leistung.
Diese Dauer wird in Sekunden oder Millisekunden gemessen und wird üblicherweise als Antwortzeit bezeichnet.
Obwohl sie "Antwortzeit" genannt wird, gibt es mehrere wichtige Schritte, die die Gesamtzeit ausmachen, die ein Client wie ein Webbrowser oder ArcGIS Pro damit verbringt, auf eine angeforderte Serverressource zu warten:
- DNS-Abfrage des Hostnamens des Servers
- SSL-Handshake zwischen Client und Server
- TCP/IP-Verbindung zwischen Client und Server
- Senden der Anfrage an den Server
- Server verarbeitet die Anfrage
- Empfangen der Antwort vom Server
- Bei großen Antworten kann stattdessen Time-to-first-byte (TTFB) verwendet werden, um die Antwortzeit zu messen
Typischerweise wird der Großteil der Zeit bei 4.1 verbracht. Hier arbeitet der Server an der Antwort.
Dieser Community-Artikel untersucht Bereiche, die diesen Teil der Antwortzeit beeinflussen können.
Warum ist Leistung wichtig?
Einfach gesagt: Je schneller die Leistung, desto niedriger die Antwortzeit.
Je niedriger die Antwortzeit, desto mehr Anfragen kann der Server gleichzeitig unterstützen.
Diese höhere Gleichzeitigkeit von Anfragen führt zu größerer Skalierbarkeit, was letztlich bedeutet Unterstützung für mehr Benutzer.
Leistung wird als Zeiteinheit gemessen, die benötigt wird, um eine einzelne Operation auszuführen (z.B. 0,238 Sekunden zur Ausführung einer Feature-Abfrage).
Skalierbarkeit hingegen wird häufig als Transaktionen oder Operationen über Zeit gemessen (z.B. Anfragen/Sekunde oder Operationen/Stunde).
Wenn man von besserer, schnellerer oder "mehr" Leistung spricht, impliziert das das Erreichen niedrigerer Antwortzeiten. Andererseits bedeutet bessere Skalierbarkeit das Erreichen einer höheren Durchsatzrate (z.B. mehr Operationen/Stunde).
Hinweis: Natürlich müssen für bessere Leistung oder Durchsatz die interessierenden Operationen angemessen ausgeführt werden und mit dem erwarteten Inhalt antworten (z.B. Kartenbild, json oder pbf-Daten). Fehlermeldungen können beispielsweise eine schnelle, einfache Antwort sein, deren Lieferung eine hohe Durchsatzrate erreichen kann. Als Tester und Analysten sind wir nicht an dieser Art von Durchsatz interessiert... wir interessieren uns für den Durchsatz erfolgreicher Anfragen.
Was ist akzeptable Leistung?
Das kommt darauf an.
Kriterien oder Anforderungen zur Klassifizierung eines Elements als schnell (oder langsam) können je nach Organisation, den veröffentlichten Diensten und den erwarteten Operationen der Benutzer stark variieren.
Es ist nicht ungewöhnlich, unterschiedliche Antwortzeitziele für ArcGIS Server-Funktionen oder Benutzeranwendungs-Workflows (mehrere Anfragen zusammengefasst als eine Operation) zu haben.
Beliebige Sekundenwerte sind als Anforderung in Ordnung, aber bedenken Sie, dass möglicherweise mehr Hardware sowie umfangreichere Abstimmungen und Strategien (dieser Artikel) erforderlich sind, um aggressive Ziele zu erreichen.
Wie wird Leistung gemessen?
Die Antwortzeit ist die Schlüsselmetrik zur Bestimmung, ob die Leistung ein Ziel erfüllt oder innerhalb eines Zielwerts bleibt.
Gängige Strategien zur Messung sind:
- Einfache Benutzerinteraktion
- Über den Webbrowser oder ArcGIS Pro
- Dies ist der einfachste Einstiegspunkt
- Wenn noch kein Verständnis zur Leistung besteht, hier beginnen
- Statistische Analyse großer Mengen von Antwortzeiten
- Durch Log-Analysetools, die ArcGIS Server Manager Statistikseite oder andere Observability-Tools
- Diese Ansätze haben den Vorteil, reale Anfragen zu analysieren, die Benutzer bereits gegen die Bereitstellung ausgeführt haben
- Dies wird später im Artikel ausführlicher behandelt
- Lasttests
- Können Einblick in Leistung und Skalierbarkeit geben
- Eingerichtet zeitaufwändiger
- Online-Ressourcen zum Einstieg sind verfügbar
Beim Analysieren von Logs oder Durchführen von Tests ist eine gängige Strategie die Nutzung von Statistiken, um große Mengen von Antwortzeiten aufzuschlüsseln. Der Durchschnitt sowie das 90. (oder 95.) Perzentil, Minimum und Maximum helfen dabei zu verstehen, welche Leistung der Benutzer möglicherweise erlebt hat.
Erfassung von Antwortzeiten – Webbrowser
Wie Antwortzeiten durch einfache Benutzerinteraktion erfasst werden können, ist ein interessantes Diskussionsthema.
Der einfachste Ansatz zur Erfassung von Antwortzeiten von REST-Anfragen aus einer Webanwendung erfolgt mit der Funktion „Entwicklertools“ des Browsers. Alle gängigen Browser bieten eine Ansicht der gesendeten und empfangenen Anfragen, Antworten und Zeiten. Diese Dauer gibt einen Eindruck davon, wie schnell eine Anfrage oder Operation (möglicherweise mehrere Anfragen) ausgeführt wurde. Anschließend kann entschieden werden, ob dies akzeptabel ist oder verbessert werden muss.
Erfassung von Antwortzeiten – ArcGIS Pro
Obwohl ArcGIS Pro ebenfalls über REST mit ArcGIS Enterprise kommuniziert, verfügt es nicht über ein eingebautes Pendant zu den Entwicklertools. Zur Erfassung von Antwortzeiten benötigen Sie einen separaten HTTP-Debugger. Es gibt viele verfügbare; eine beliebte Wahl ist Fiddler.
Mithilfe von Fiddler auf demselben Rechner wie ArcGIS Pro kann der Datenverkehr abgefangen werden. Anfrageparameter, Antwortinhalte und Zeiten können ähnlich erfasst und untersucht werden.
Sind Ziele erforderlich zur Leistungsverbesserung?
Nicht unbedingt. GIS-Administratoren können das System jederzeit analysieren, optimieren und bewährte Verfahren anwenden – auch wenn keine offiziellen Leistungsanforderungen vorliegen.
Es wird jedoch dringend empfohlen zu verstehen, welche Leistung Ihr System anfänglich liefert (z.B. werden diese typischerweise als Basis-Antwortzeitwerte bezeichnet), bevor Anpassungen vorgenommen werden. So können Sie feststellen, ob sich die vorgenommenen Änderungen positiv auswirken.
Häufige Leistungsprobleme und mögliche Strategien
Dienst-Pool-Typen und Instanzen
Einer der häufigsten Bereiche, in denen GIS-Administratoren auf Leistungsprobleme stoßen, ist das Festlegen der angemessenen Anzahl von Instanzen für dediZierte-Dienste. Aber zuerst wollen wir die verschiedenen Typen betrachten.
Es gibt 3 Diensttypen mit jeweils eigenen Stärken.- dediZiert
- wird gehostet
- Gemeinsam genutzt </ LI ></ UL >< DIV >< P >Als GIS-Administrator ist es wichtig , den Instanztyp für einen service.<\/P>Dies kann einfach im ArcGIS Server Manager unter Manage Services eingesehen werden:<\/DIV>
<\/DIV>
<\/span><\/P><\/DIV>Auswahl des geeigneten Typs<\/SPAN><\/H3>Die Wahl eines dedizierten Servicetyps ist ideal, wenn die beste Leistung und Skalierbarkeitskontrolle gewünscht wird<\/U>. Mit diesem Typ kann der Administrator:<\/P><\/DIV>Die maximale Anzahl von Instanzen auf die Anzahl der CPU-Kerne einstellen, um die verfügbare Verarbeitungskapazität der ArcGIS Server-Maschine voll auszunutzen (über das Maximum)<\/SPAN><\/LI>Speicher im Leerlauf sparen (über das Minimum)<\/SPAN><\/LI>Für vorhersehbare Leistung Min und Max auf denselben Wert setzen<\/SPAN><\/LI><\/UL>Dedizierte Dienste sind ideal für stark angefragte Dienste oder Dienste, bei denen Leistung oberste Priorität hat.<\/P>Hosted Services nutzen keine ArcSOC-Instanzen und skalieren bei Bedarf automatisch. Die ArcGIS-Funktionalitäten, die ihnen (Hosted) zur Verfügung stehen, sind jedoch begrenzt, da sie hauptsächlich für Feature-Abfragen verwendet werden.<\/P>Shared Services eignen sich hervorragend für den Zugriff auf weniger häufig angefragte Elemente. Sie haben in der Regel mehr ArcGIS-Funktionalitäten verfügbar, aber nicht alle ArcGIS-Funktionen sind verfügbar (z. B. Branch-Versionierung). Ein Shared Instance Pool ist der Standardtyp beim Veröffentlichen eines Dienstes mit ArcGIS Pro<\/U>.<\/P>Hinweis: Es ist wichtig zu betonen, dass wenn der ausgewählte Servicetyp auf dediziert gesetzt ist, die (minimale und maximale) Anzahl der Instanzen überprüft werden sollte, um sicherzustellen, dass sie optimal sind. Der Standard beim Veröffentlichen in ArcGIS Pro ist es, nur maximal 2 (Instanzen) zu verwenden. Dies könnte zu niedrig und unzureichend sein für Dienste, bei denen Leistung und Skalierbarkeit wichtig sind.<\/STRONG><\/FONT> <\/SPAN><\/P><\/DIV>Karte fokussieren<\/H2>Die Optimierung der Karte ist keine neue Strategie, sondern eine relativ einfache Methode, um eine bessere Leistung aus Ihrer Bereitstellung zu erzielen.
Wenn die Karte auf ihren Hauptzweck und ihre Präsentation fokussiert ist, muss das System keine unnötige Arbeit leisten. Denken Sie daran, das Web ist eine Multiuser-Plattform. Die Anzeige der dynamischen Daten so schlank wie möglich zu gestalten, ist der Schlüssel zu guter Leistung (und Skalierbarkeit). Da potenziell viele Anfragen gleichzeitig erfolgen, muss der geteilte Inhalt so effizient wie möglich sein.<\/P>
<\/span>Kartenstrategien<\/SPAN><\/H3>Wählen Sie einen optimalen Standard-Ausschnitt<\/SPAN>Wenn die Karte Daten über Los Angeles bereitstellt, sollte der Standard-Ausschnitt nicht<\/EM> ganz Kalifornien zeigen<\/LI>Wenn viele verschiedene Kartenmaßstäbe erforderlich sind, verwenden Sie Maßstabsabhängigkeiten und Generalisierung, um die Details auf das Wesentliche zu beschränken (z. B. die größten Maßstäbe)<\/LI><\/UL><\/LI>Entfernen Sie nicht benötigte LayerZiehen Sie in Betracht, „Nice-to-have“-Datenlayer zu entfernenZumindest sollten diese abgewählt werden und Benutzer müssen aktiv zustimmen, um sie zu aktivieren<\/LI><\/UL><\/LI><\/UL><\/LI>Beschränken Sie bewusst, was Benutzer mit einem Dienst tun können<\/LI>Vermeiden Sie Projektionen on the flyVerwenden Sie dasselbe Koordinatensystem für Datenrahmen und Daten<\/LI><\/UL><\/LI>Definition QueriesStellen Sie sicher, dass Indizes vorhanden sind, wenn Vergleichslogik auf Attributspalten angewendet wird <\/LI><\/UL><\/LI><\/UL>Hinweis: "Karte fokussieren" gilt für Karten, Apps und Dienste<\/FONT><\/STRONG><\/DIV>Software-Releases<\/H2>Eine bestimmte Version von ArcGIS Enterprise (und seinen zugehörigen Lösungen) kann nach ihrer ersten Basisversion einige Patches erhalten. Diese Patches können Leistungsverbesserungen sowie Funktions- und Sicherheitskorrekturen bieten. <\/P>Es wird dringend empfohlen, regelmäßig die Esri Patches and Updates<\/A> Seite zu überprüfen oder das Tool "Check for ArcGIS Enterprise Updates" auszuführen. Wenden Sie dann die Updates zum passenden Zeitpunkt an.<\/P>
Ressourcenkonflikte und Erweiterung<\/H2>Es gibt Zeiten, in denen Best Practices und Strategien für Leistung angewendet werden, aber dennoch niedrigere Antwortzeiten und höhere Skalierbarkeit erforderlich sind. Vielleicht ist die aktuelle Hardware, auf der ArcGIS Server läuft, einfach erschöpft, wobei die Verarbeitungskapazität oder der Speicher zum Engpass für die Verbesserung der Benutzererfahrung geworden sind.<\/P>Für solche Situationen müssen Sie eine Erweiterung und/oder ein Upgrade der Hardware in Betracht ziehen.<\/DIV>
Skalierbarkeit<\/SPAN>
Für die ArcGIS Server- und ArcGIS Web Adaptor-Ebenen der Bereitstellung haben Sie in der Regel<\/ id="toc-hId-333806091">Observability
"Quantifying ArcGIS" ist eine großartige Strategie...ein persönlicher Favorit. Sie definiert, welche Ressourcen angefordert wurden und wie schnell die Antworten zur Erfüllung dieser Anfragen erfolgten. Dies ist wichtig, um ein Verständnis der allgemeinen Systemleistung zu erhalten. Wenn auch die Systemressourcennutzung erfasst werden kann, kann die Analyse weiter vertieft werden.
Es gibt viele Dienstprogramme, die zur periodischen Überprüfung Ihres Systems verfügbar sind. Einige Tools lesen möglicherweise die Zugriffsprotokolle und konzentrieren sich hauptsächlich auf die statistische Anforderungsleistung der Benutzer. Andere können die Statistikseite des Servers abfragen und die CPU-Auslastung (des ArcGIS Server oder der Datenbank) für diesen Zeitraum erfassen. Welcher Ansatz ist am besten? Wenn derzeit keine Observability stattfindet, dann ist wahrscheinlich jeder von ihnen eine gute Ergänzung. Sie alle helfen dabei, eine Art Einblick in die Leistung und den Zustand der Bereitstellung zu geben.
Nachdem eine Analyse für eine Bereitstellung durchgeführt wurde, können typischerweise Berichte erstellt werden, die hervorheben, welche Kartendienste aufgrund folgender Punkte von Interesse sein könnten:
- Die beobachteten Antwortzeiten langsamer als erwartet sind
- Die Anzahl der Anfragen für die Ressource
- Sowohl Antwortzeit als auch Anzahl der Anfragen
Für eine ArcGIS Site mit vielen Diensten hilft es zu wissen, welche statistisch langsam sind oder die meisten Ressourcen verbrauchen, um Tuning-Maßnahmen zu fokussieren. Mit solchen Berichten hat der GIS-Administrator Daten in wertvolle Informationen verwandelt und ist nun besser informiert, um Entscheidungen zur Verbesserung der Benutzererfahrung zu treffen. Das heißt, das Untersuchen von Protokollen und Statistiken ist nur ein (wichtiger) Teil des Analyseprozesses.
Eine Herausforderung bei gängigen Observability-Tools
Viele Tools zur Systemobservability und -überwachung konzentrieren die Analyse auf Anfragen und Antworten für Dienste. Dies ist ein guter Ansatz und unterstützt Administratoren definitiv bei der Quantifizierung von ArcGIS, kann aber eine Einschränkung haben. Die Einschränkung kann darin bestehen, dass angenommen wird, ein langsamer Kartendienst könne einfach durch Hinzufügen von Verarbeitungskernen "behoben" werden. Mehr Kerne könnten einige Aspekte verbessern, aber es wird empfohlen, den Dienst vor dem Hinzufügen weiterer Ressourcen genauer (oder erneut) zu untersuchen.
Dies geht zurück auf den Abschnitt "Focus the Map", zum Beispiel:
- Sicherstellen, dass die Daten für den Dienst nicht in zu kleinen Maßstäben angezeigt werden
- Suboptimale Abfragen vermeiden
Detaillierte Abfrageanalysen können helfen, das Auftreten dieser Verhaltensweisen aufzuzeigen, die in allgemeinen Dienstberichten möglicherweise verdeckt bleiben. Allerdings kann die Aufschlüsselung von Dienstanfrageparametern und den zugrunde liegenden Abfragen zwar die Analyse verbessern, aber auch Komplexität im Bericht selbst hinzufügen (z.B. längere Ausführungszeiten, mehr Ansichten dessen, was betrachtet werden muss, das Verständnis der Ansichten). Außerdem führen nicht alle Observability-Tools diese Art von Inspektion durch.
Einige neuere Bemühungen, die an Bedeutung gewinnen, versuchen dieses Problem anzugehen. Sie basieren auf einem Bottom-up-Analyseansatz, bei dem der Ausgangspunkt die zugrunde liegenden Datenbankabfragen selbst sind – durch einen Mechanismus bekannt als "query datastore". Die Analyse des query datastore ist leistungsstark und beeinträchtigt nicht die Datenbankleistung wie ein trace, erfordert jedoch Kenntnisse über die Abfragen selbst und deren Zweck. Erwarten Sie zukünftig diese Art von Analysefunktionalität, um das Beste aus Ihren Observability-Tools herauszuholen.
Fazit
Es gibt keinen einzelnen Punkt, der leicht angepasst werden kann, um Leistung und Skalierbarkeit einer ArcGIS Enterprise Site zu steigern. Dieser Artikel listet jedoch einige gängige Strategien auf, die zusammen angewendet werden können, um Verbesserungen zu erzielen. Es ist auch wichtig zu verstehen, dass diese Punkte regelmäßig überprüft und umgesetzt werden sollten. Nutzergewohnheiten ändern sich im Laufe der Zeit ebenso wie die Beliebtheit einer Webanwendung oder eines Dienstes. Ressourcen, die einem bestimmten Dienst zugewiesen wurden, können neu bewertet oder reduziert werden, um Platz für das nächste Highlight in Ihrer Site zu schaffen.
Die Leistungsanalyse von ArcGIS kann Spaß machen, ist aber auch eine kontinuierliche Aufgabe zur Aufrechterhaltung der besten Benutzererfahrung.
Quellenangabe
Ressource: Datei:Grayson_running_the_4x100.jpg
Beschreibung: Englisch: Grayson läuft das erste Teilstück des 4x100 beim Tigered-Einladungslauf 2010
Autor: Graysonbay
Erstellt: 02:02, 29. November 2010
Lizenz: Diese Datei ist lizenziert unter der Creative Commons Attribution 3.0 Unported Lizenz
Ressource: Datei:Kurvimeter_1_fcm.jpg
Autor: Frank C. Müller, Baden-Baden
Lizenz: Diese Datei ist lizenziert unter der Creative Commons Attribution-Share Alike 4.0 International Lizenz.
Ressource: Datei:My_Opera_Server.jpg
Beschreibung: Ein Server verwendet für My Home
Autor: William Viker, william.viker@gmail.com (c) 2006
Lizenz: Der Urheberrechtsinhaber dieser Datei erlaubt jedem ihre Nutzung für jeden Zweck unter der Voraussetzung, dass der Urheberrechtsinhaber ordnungsgemäß genannt wird. Weiterverbreitung, abgeleitete Werke, kommerzielle Nutzung und alle anderen Nutzungen sind erlaubt.
Ressource: Datei:Samsung-1GB-DDR2-Laptop-RAM.jpg
Beschreibung: Ein 1 Gigabyte DDR2 667 MHz (PC2-5300) Laptop-RAM-Stick von Samsung aus einem MacBook Laptop von 2007.
Autor: Evan-Amos
Erstellt: 1. August 2018
Lizenz: Public Domain
