ArcSOC-Verfügbarkeit und -Nutzung
Die Optimierung der Verfügbarkeit und Nutzung der ArcSOC-Instanz für Ihren Service ist eine gute Strategie, um Benutzern schnelle Reaktionszeiten und kürzere Wartezeiten bei ihren dynamischen Anfragen an Ihre Site zu ermöglichen. Dies kann auch die Ressourcennutzung des Servers wie den Speicher verbessern, da der Dienst nicht viele Instanzen ausführt, die er niemals verwenden wird.
Die Optimierung der minimalen und maximalen Anzahl von Instanzen für Ihre dedizierten Dienste ist jedoch keine einmalige Aufgabe. Die Nutzungsmuster Ihrer Dienste können sich im Laufe der Zeit ändern, sodass die Aufgabe, diese Informationen zu sammeln, etwas ist, das Sie als GIS-Administrator regelmäßig überprüfen möchten.
Bevor wir uns damit befassen, wie man ArcSOC-Instanzaktivitätsstatistiken beobachtet, lassen Sie uns einige der wichtigsten Details der beiden auf ArcSOC basierenden Servicetypen in ArcGIS Server überprüfen und wie sie in diese Diskussion einfließen:
Hinweis: Wartezeit ist die Dauer, die eine Anfrage in einer "Warteschlange" auf dem Server verbringt, bis eine ArcSOC-Instanz verfügbar ist, um mit der Bearbeitung zu beginnen.
Dedizierte Instanz-Pool-Dienste
Dedizierte Dienste (z. B. nicht gehostete und nicht geteilte Dienste) sind eine feste Größe in ArcGIS-Bereitstellungen, da viele Anwendungen auf Funktionen wie Geoverarbeitung, Branch Version-Bearbeitung und Utility Network-Workflows angewiesen sind (alle erfordern dedizierte Dienste).
Obwohl solche Dienste sehr vielseitig sind und eine wichtige Säule in ArcGIS aufgrund ihrer Funktionalität darstellen, müssen Sie als GIS-Administrator regelmäßig die Anzahl der ArcSOC-Instanzen (Minimum und Maximum) überprüfen, anpassen und konfigurieren, um Ihre verfügbaren Ressourcen optimal zu nutzen, während Ihre Site und Benutzer wachsen.
Um mehr über ArcSOC-Instanzen zu erfahren, siehe: Verstehen von Service-Instanzen
Einschränkungen von Shared Instance Pool Services
Geteilte Service-Instanzen sind großartig! Sie sind wirklich ein Wendepunkt für Administratoren, um die Nachfrage vieler Dienste mit begrenzten Ressourcen zu verwalten. Allerdings schränken ihre Beschränkungen und Anforderungen ein, welche Service-Funktionalitäten mit ihnen verwendet werden können. Geoverarbeitung, Branch Version-Bearbeitung und Utility Network werden beispielsweise derzeit nicht über geteilte Dienste (oder über gehostete Dienste) unterstützt. Dies lässt dedizierte Dienste als einzige Wahl für solche Funktionalitäten.
Konfigurierte ArcSOC-Instanzverfügbarkeit vs. Instanznachfrage
Für Dienste, die sehr beliebt, kritisch sind und/oder die Anforderung haben, unter dem dedizierten Servicetyp ausgeführt zu werden, ist das Verständnis der optimalen Instanzeinstellung aus mehreren Gründen wichtig. Wenn die maximale Anzahl aktiver Instanzen zu hoch ist, wird Speicher verschwendet (sowie Kosten). Die Überallokation von ArcSOC-Instanzen ist ein wichtiger aber einzigartiger Fall, da sich dessen Auswirkung nicht nur in der Analyse der Reaktionszeiten zeigt.
Andererseits kann eine zu niedrige maximale Anzahl die Leistung beeinträchtigen (in Form von höheren Reaktionszeiten und längeren Wartezeiten), da Benutzer möglicherweise häufig darauf warten müssen, dass eine bereits beschäftigte ArcSOC-Instanz frei wird.
Natürlich hat das Setzen unterschiedlicher Werte für Minimum und Maximum der Instanzen auch einen Kompromiss. Für kritische Dienste, bei denen Leistung oberste Priorität hat, kann es zeitaufwendig sein und die Leistung beeinträchtigen, wenn die Anfrage des Benutzers warten muss, während eine Instanz gestartet wird. Daher wird für vorhersehbare Leistung bei wichtigen Diensten empfohlen, Minimum und Maximum der Instanzen auf denselben Wert zu setzen.
Wie auf Einführung in Service-Instanzen aufgeführt:
Dementsprechend ist es wichtig für ArcGIS Server -Administratoren, die Anzahl der laufenden Instanzen ihrer Site zu überwachen und laufende Instanzen zu begrenzen, wenn die Leistung durch Speichernutzung beeinträchtigt wird.
Die Konfiguration der Verfügbarkeit des Dienstes (durch seine minimalen und maximalen Instanzen) und die Auswirkungen dieser Einstellungen auf die Nachfrage der Benutzer am Dienst sind entscheidend für einen optimal laufenden Site. Es besteht eine wechselseitige Beziehung zwischen der Konfiguration der Verfügbarkeit des Dienstes (durch minimale und maximale Instanzen) und dem direkten Einfluss auf eingehende Anfragen an einen dedizierten Dienst. Während das Finden der optimalen Einstellung eine fortlaufende Aufgabe ist, gibt es einige Werkzeuge und Ressourcen zur Unterstützung von Administratoren bei dieser Herausforderung.
ArcGIS Server Service Report
Der ArcGIS Server Service Report (eingeführt in 10.1) ist eines dieser weniger bekannten REST Admin API-Schätze. Diese Ressource kann helfen, eine Site zu überwachen, indem sie eine konfigurierbare Zusammenfassung aller Dienste in einem Ordner bereitstellt. Es handelt sich im Allgemeinen um eine schnell ausführbare Anfrage (abhängig von der Anzahl der angeforderten Dienste im Ordner).
Der Abschnitt Instanz-Service-Statistiken der zurückgegebenen Antwort ist äußerst wertvoll, da er Details zu den ArcSOC-Instanzen (min., max., beschäftigt) über die gesamte Bereitstellung hinweg auflistet (z.B. die ArcGIS Server Site).
Durch periodisches Abfragen dieses Endpunkts kann man Echtzeit-Einblicke in die Konfiguration der Service-Instanzen im Vergleich zur Nachfrage gewinnen... während es passiert. Mit solchen Informationen können bessere Entscheidungen zur Optimierung von Maschinen- und Dienstressourcen getroffen werden. Dies kann wiederum helfen, Reaktionszeiten zu verbessern und Wartezeiten zu verkürzen.
Hinweis: In ArcGIS Server sind Instanz-Service-Statistiken Informationen und die Statistikenseite im Manager tatsächlich unterschiedliche Ressourcen sind, obwohl sie ähnliche Ansichten derselben Daten bieten. Die Service-Statistiken bieten Rohzugriff auf die Instanzwerte (Site-weite und pro Maschine) sowie mehr Details. Die Statistikenseite ist eine Schnittstelle zum Erstellen von Berichten aus einigen dieser Informationen.
Automatisierung der Service Report-Erfassung mit Soccer
Jedes Skript, Programm oder Tool, das regelmäßig den Service Report-Endpunkt des interessierenden Ordners beobachtet, wäre ausreichend. Wenn Sie jedoch nach einem kostenlosen bestehenden Tool suchen, wird Soccer empfohlen.
(Arc)SOC ScannER oder Soccer ist ein Dienstprogramm zum Scannen und Lesen der Dienststatistiken eines bestimmten ArcGIS Server-Ordners. Es analysiert die gesammelten Daten und schreibt sie in eine CSV-Datei für zusätzliche Nachbearbeitungsanalysen (z.B. Erstellung von Diagrammen in einer Tabellenkalkulation zur Visualisierung der Nutzung). Es nutzt die REST Admin Service Report-Ressource in ArcGIS Server zur Informationssammlung. Das ursprüngliche Ziel von Soccer war es, den Berichtsausgabe-Endpunkt eines bestimmten Ordners in ArcGIS Server zu erfassen und die ArcSOC-Instanzstatistiken (z.B. Running, Busy, Maximum usw.) für jeden Dienst zu speichern.
Derzeit ist Soccer nur ein Befehlszeilen-Dienstprogramm. Es wird im .NET 6.0 portablen Laufzeitumgebung für Windows (win-x64), Linux (linux-x64) und macOS (osx-x64) bereitgestellt.
Zur Vereinfachung benötigt das Ausführen von Soccer nur 3 Eingaben (andere Parameter können zur Erweiterung der Funktionalität übergeben werden):
soccer.exe -s "[https://ArcGISServer/ServerWebAdaptor]" -f [FolderToScan] -t "[PreGeneratedArcGISToken]"
Zum Beispiel:
soccer.exe -s "https://gisserver.domain.com/server" -f "Gas" -t "APLeyWOcKZp9stZ_C01DQ.."
Hinweis: Ein vorab generiertes ArcGIS Server-Token kann vom Portal bezogen werden. Typischerweise ist die generateToken-URL: https://gisserver.domain.com/portal/sharing/rest/generateToken und die Webapp-URL wäre dann: https://gisserver.domain.com/server/admin. Setzen Sie den Ablaufwert auf einen für Ihre erwartete Überwachungsdauer angemessenen Wert.
Standardausgabe beim Ausführen aus einem Befehlsfenster:
Verbunden mit: "https://gisserver.domain.com/server " (Gas)
Drücken Sie zweimal Strg-C, um zu stoppen...
Schlafe 5 Sekunden...
Beim Ausführen verbindet sich soccer mit dem Service Report-Endpunkt des angegebenen ArcGIS Server-Ordners, sammelt die Daten, schreibt sie in eine lokale CSV-Datei und schläft dann. Nach Ablauf der Schlafdauer wiederholt es den Vorgang. Soccer sammelt weiter, bis der Prozess manuell gestoppt wird (Strg-C).
Hinweis: Um im Root-ArcGIS Server-Ordner zu sammeln, verwenden Sie entweder: -f "/" oder -f ""
Analyse der CSV-Datei
Beispielinhalt, wie er in einem einfachen Textbetrachter zu sehen ist:
DateTime,Epoch,IntervalSeconds,Host,Folder,ServiceName,Type,Provider,Running,Busy,Maximum,Free,NotCreated,Initializing,Transactions,TotalBusyTime,ServicesCollected,ResponseTimeMilliseconds,ContentLength,ConfiguredState,RealTimeState,Message
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,succes
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,succes
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,117.901,6065,STARTED,STARTED,succes
5/2/2023 1:12:50 AM,...
Hinweis: Designbedingt zeigen Spalten wie IntervalSeconds und ResponseTimeMilliseconds doppelte Werte an wenn mehr als ein Dienst im beobachteten Ordner existiert.
Die gesammelten Daten sind eine typische CSV-Datei. Es gibt jedoch einige wichtige Felder zur schnellen Analyse der ArcSOC-Aktivität unserer interessierenden Dienste:
- IntervalSeconds
- ServiceName
- Running
- Busy
- Maximum
Durch Öffnen der CSV-Datei in einer Tabellenkalkulation können andere Dienste im selben Ordner leicht über die Spalte ServiceName herausgefiltert werden. Die Werte von IntervalSeconds sowie Running-, Busy- und Maximum-Werten können dann geplottet werden (z.B. durch das Streudiagramm mit geglätteter Linie) und zeigen die Instanzkonfiguration im Vergleich zur eingehenden Nachfrage. In diesem Fall war der Dienst Gas_Utility_Network auf eine min/max Instanzkonfiguration von 32/32 eingestellt.
Das „polierte“ Diagramm unten:
Hinweis: Maximum und Running repräsentieren die maximale bzw. minimale ArcSOC-Dienstinstanzkonfiguration. In diesem Fall haben Running und Maximum dieselben Werte und Running wird „hinter“ Maximum dargestellt. Busy zeigt die Anzahl der aktiven Instanzen (aufgrund von Benutzeranfragen) über alle Maschinen im Site an.
Das Ziel der Abstimmung und Optimierung wäre hier zu vermeiden dass die Busy-Werte ständig das Maximum erreichen. Wenn dies passiert bedeutet es dass nicht genügend ArcSOCs für den Dienst verfügbar waren um die Benutzernachfrage zu erfüllen da die Instanzen immer beschäftigt waren. Benutzeranfragen würden dann höchstwahrscheinlich erhöhte Antwortzeiten und Wartezeiten erfahren. Wenn Anfragen zu lange warten timeouten sie (typischerweise nach 60 Sekunden). Viele Service-Anfrage-Timeouts würden die Benutzererfahrung negativ beeinflussen.
Basierend auf den Beobachtungen dieser überwachten Dauer kamen die Schwankungen der Busy-Spaltenwerte nicht annähernd an die maximale Anzahl verfügbarer Instanzen heran – was aus einer Perspektive gut war. Allerdings zeigte dies auch dass eine messbare Anzahl von Instanzen lief und Speicher belegte ohne genutzt zu werden – was nicht ideal war.
Um Systemressourcen zukünftig zu optimieren könnte die Instanzkonfiguration dieses Dienstes auf einen niedrigeren Wert gesetzt werden der näher am (erwarteten) Spitzenverbrauch liegt (z.B. irgendwo zwischen 18 – 24).
- Verwenden Sie 18 um Speicher zu sparen mit dem Risiko dass mehrere Instanzen Benutzer länger warten lassen
- Verwenden Sie 24 um Leistung gegenüber Speicherverbrauch zu bevorzugen
Abschließende Gedanken
Eine „optimierte“ Dienstkonfiguration für minimale und maximale Instanzanzahl garantiert nicht dass Benutzer niemals langsame Leistung erleben. Benutzerbedürfnisse und -gewohnheiten ändern sich im Laufe der Zeit; daher muss diese Information regelmäßig überwacht werden.
In der Praxis gibt es Bedingungen unter denen Service-Wartezeiten trotz ausreichender Instanzen und Systemressourcen auftreten können. Es ist unrealistisch Wartezeiten komplett zu eliminieren; realistischer ist es sie zu reduzieren. Die Optimierung der Dienstinstanzen ist ein direkter Einflussbereich von Administratoren mit Auswirkungen auf Wartezeiten.
Das Verständnis und die regelmäßige Bewertung der ArcSOC-Instanzkonfiguration (für dedizierte Dienste) und deren Beziehung zur Benutzernachfrage ist entscheidend um GIS-Administratoren bei Planung und Verwaltung ihrer Site durch Leistungsoptimierung und effiziente Ressourcennutzung zu unterstützen.
