Skip to main content

Optimieren von Services für die Anforderungen der Benutzer

Die Standardwerte der Service-Eigenschaften sind möglicherweise nicht für die Anforderungen der Benutzer geeignet. Das gilt besonders, wenn die Anzahl der Benutzer groß ist oder wenn sie viele Anforderungen an die ArcGIS-Server-Site senden. Dieses Thema bietet eine Übersicht über Konzepte, Eigenschaften und Methoden, mit denen Sie die Services optimal konfigurieren können.

Informationen zu Service-Instanzen

Wenn in der ArcGIS Server-Site z. B. die Service-Anforderung eingeht, eine Karte zu schwenken, zu einer Adresse zu navigieren oder ein Bild mit einer Rendering-Regel anzuzeigen, wird sie von einer Instanz des veröffentlichten Services verarbeitet, die auf einem Servercomputer ausgeführt wird. Service-Instanzen werden von proprietären Esri Serverprozessen – den ArcSOC-Prozessen – unterstützt. Für die Ausführung des jeweiligen ArcSOC-Prozesses wird eine bestimmte Menge an Computerspeicher benötigt.

Wenn die ArcGIS Server-Site viele Services enthält und jeder Service eine oder mehrere Service-Instanzen verwendet, die ständig ausgeführt werden, hat der verfügbare Computerspeicher möglicherweise irgendwann seine Grenzen erreicht. Für die Ausführung der Service-Instanzen entstehen Ihrer Organisation außerdem Energiekosten. Wenn Sie ArcGIS Server in einer Cloud-Infrastruktur bereitstellen, fallen zudem direkte finanzielle Kosten für jede ausgeführte Service-Instanz an.

Aus diesem Grund ist es wichtig, dass ArcGIS Server-Administratoren die Anzahl der in der Site ausgeführten Instanzen überwachen und diese begrenzen, wenn die Performance durch die Speicherauslastung beeinträchtigt wird.

Benutzer erwarten schnelle Ergebnisse, wenn sie mit Services (einschließlich Produkten, die auf Basis von Services entwickelt wurden, wie z. B. Webkarten und Apps) interagieren. Für die Verarbeitung des Datenverkehrs, der an die Services gesendet wird, sind entsprechende ArcSOC-Prozesse erforderlich. Durch die Bereitstellung von mehr Serverressourcen als ein Service benötigt werden jedoch unnötig viel Computerspeicher, Energie und finanzielle Mittel verbraucht. Deshalb sollten Administratoren immer zum Ziel haben, die ausgeführten Service-Instanzen auf die tatsächlich erforderliche Anzahl zu reduzieren, ohne dass dies zu Lasten der Performance geht.

Geteilte oder dedizierte Service-Instanzen

ArcGIS Server ermöglicht die Verwendung von sowohl geteilten als auch dedizierten Instanzen für den jeweiligen kompatiblen Karten- oder Image-Service, der über ArcGIS Pro in einer ArcGIS Server-Site veröffentlicht wird. Durch die Verwendung freigegebener Instanzen verringert sich die Speicherauslastung, da mehrere aktive Serverprozesse zur Verwendung durch mehrere Services gepoolt werden. Dedizierte Instanzen sorgen hingegen dafür, dass ein Service für die Verarbeitung von Anforderungen ständig verfügbar ist, indem ein oder mehrere Serverprozesse verwendet werden. Sie eignen sich deshalb ideal für Services, die konstante oder besonders rechenintensive Anfragen empfangen.

Für neue Bereitstellungen von ArcGIS Server werden standardmäßig geteilte Instanzen verwendet. Administratoren können jederzeit sowohl einen Standard-Instanztyp auswählen (festlegen, ob kompatible Kartenservices zunächst geteilte oder dedizierte Instanzen verwenden sollen) als auch den Instanztyp eines einzelnen Service ändern.

Tipp:

Um festzustellen, über welche Anwendung ein Service veröffentlicht wurde, sehen Sie sich die Eigenschaften "Service Runtime" und "Instanztyp" für jeden Service in der ArcGIS Server Manager-App an.

Die folgenden Beschränkungen begrenzen, welche Services den Pool für geteilte Instanzen verwenden dürfen:

  • Nur Karten- und Image-Services können für die Verwendung des Pools für geteilte Instanzen konfiguriert werden. Andere Service-Typen, wie etwa Geoverarbeitungsservices, werden nicht unterstützt.

  • Nur folgende Funktionen können aktiviert werden: Kartenerstellung, Imaging, Feature Access, WFS, WMS und KML. Deaktivieren Sie alle anderen Funktionen, bevor Sie einen geteilten Service statt eines dedizierten Services verwenden.

Eine dedizierte Instanz des Karten- oder Image-Service wird mit einem bestimmten Pool von ArcSOC-Prozessen ausgeführt. Die Prozesse in diesem Pool werden für keinen anderen Service verwendet. Eine geteilte Instanz des Karten- oder Image-Service wird mit einem Pool von ArcSOC-Prozessen ausgeführt, die auch für eine geteilte Instanz jedes anderen Service verwendet werden. Standardmäßig cacht jeder ArcSOC-Prozess für eine geteilte Instanz die 50 zuletzt genutzten Services, sodass sie Anforderungen sofort behandeln können. Wenn ein ArcSOC-Prozess für eine geteilte Instanz bereits die maximale Anzahl an Services gecacht hat und ein Benutzer eine Anforderung für einen neuen Service ausführt, entlädt der ArcSOC-Prozess den Service, der vor der längsten Zeitspanne verwendet wurde, und lädt den neuen Service. Wenn Benutzer regelmäßig Anforderungen in mehr als 50 Instanzen geteilter Services ausführt, können Sie die Standardanzahl der gecachten Services pro geteilter Instanz erhöhen.

Verwenden der jeweiligen Instanztypen

Im Allgemeinen wird die Verwendung geteilter Instanzen statt dedizierter Instanzen empfohlen. Geteilte Instanzen bieten eine höhere Gesamteffizienz, da sie die gleiche mittlere Performance und den gleichen Durchsatz haben, aber deutlich weniger Systemressourcen benötigen.

Es gibt zwei Situationen, in denen dedizierte Instanzen empfohlen werden.

  • Wenn geschäftliche Gründe erfordern, dass eine kleine Anzahl von Services eine höhere Performance und Skalierbarkeit im Vergleich zu anderen Services aufweist.

  • Wenn Funktionalität in geteilten Instanzen wie SOEs, die nicht threadsicher sind, oder für Versorgungsnetze nicht unterstützt wird.

Die Ausweisung von Services als dediziert verbessert die Performance nicht automatisch. Um die Performance mit dedizierten Instanzen zu verbessern, müssen Sie außerdem die Anzahl der verfügbaren Instanzen für geteilte Instanzen reduzieren und die Anzahl der Instanzen für den eigenen Service sorgfältig festlegen. Die Ausweisung von zu vielen Services als dediziert beeinträchtigt wahrscheinlich die Performance. Es wird empfohlen, möglichst wenig dedizierte Karten- oder Image-Services pro Standort zu verwenden.

Karten- und Image-Services sind CPU-intensiv. Normalerweise ist der Durchsatz eines ArcGIS-Servers, der für Karten- und Image-Services vorgesehen ist, durch die Anzahl der CPU-Kerne begrenzt. Wenn der Server-Computer acht Kerne aufweist und alle Services geteilte Instanzen sind, erreicht der maximale Durchsatz wahrscheinlich seinen Maximalwert, wenn der Computer acht Anforderungen gleichzeitig verarbeitet. ArcGIS Server verarbeitet mehr Anforderungen, aber für diese zusätzlichen Anforderungen werden CPUs gemeinsam genutzt. Alle Services, die geteilte Instanzen verwenden, werden mit derselben Priorität behandelt und können die volle CPU-Leistung des Servers nutzen.

Dedizierte Instanzen sind für einen Service geeignet, der eine konstante Leistung verlangt, auch wenn dies die Performance anderer Services verringert. Wenn Sie zum Beispiel acht Kerne haben, können Sie die Hälfte davon nur für diesen einen Service reservieren, indem Sie die Mindest- und Maximalanzahl der dedizierten Instanzen auf vier festlegen. Um sicherzustellen, dass für diesen dedizierten Service jederzeit mindestens vier Kerne verfügbar sind, können Sie die Anzahl der geteilten Instanzen auf vier reduzieren, sodass nie mehr als die andere Hälfte der acht Kerne verwendet wird.

ArcGIS Server ermöglicht eine Überallokation von Instanzen. Das bedeutet, dass Sie für einen Computer, der nur acht Kerne hat, mehr Instanzen als die Anzahl der Kerne zuweisen können. Überallokation ist möglich, bewirkt jedoch, dass die Performance schwierig vorherzusagen und zu steuern ist. Eine Überallokation von 10 bis 20 % kann die Effizienz verbessern, aber ein hoher Faktor der Überallokation beeinträchtigt wahrscheinlich die Performance. Statt durch Überallokation dedizierter Instanzen erhöhen Sie die Performance wahrscheinlich eher durch das Umwandeln einiger dedizierter Instanzen in geteilte Instanzen.

Minimale und maximale Anzahl an Service-Instanzen

Wenn ein Service dedizierte Instanzen verwendet, können Sie die minimale und maximale Anzahl an Instanzen anpassen, die pro Computer zulässig sind. Mithilfe dieser Parameter können die Services Ihrer Site besser auf Schwankungen im Datenaufkommen abgestimmt werden.

Die Eigenschaft "Minimale Anzahl Instanzen" stellt die Anzahl dedizierter Instanzen dar, die bereits erstellt wurden und für einen Service zur Verwendung auf den einzelnen ArcGIS Server-Computern verfügbar sind. Wenn Sie diesen Parameter beispielsweise auf drei Instanzen festlegen, werden immer mindestens drei Instanzen für ArcSOC-Prozesse ausgeführt, auch dann, wenn der Service keine Anforderungen empfängt. Wenn Sie bezweifeln, dass ein Service von vielen Benutzer gleichzeitig verwendet werden wird, sollten Sie eine Reduzierung der Mindestanzahl von Instanzen in Erwägung ziehen.

Die Eigenschaft "Maximale Anzahl Instanzen" legt die Höchstzahl der Instanzen des jeweiligen Service fest, die auf einem einzelnen ArcGIS Server-Computer ausgeführt werden können. Als Administrator sollten Sie zu bestimmen versuchen, wie viele Instanzen einer Service-Konfiguration den erwarteten Benutzerbedarf unter Wahrung eines akzeptablen Leistungsniveaus zufriedenstellen kann.

Die Anzahl der Instanzen, die in einer Service-Konfiguration erforderlich sind, lässt sich am besten durch die Überwachung des Servers über einen längeren Zeitraum ermitteln. Wenn die Wartezeiten der Clients zu lang sind oder bei der Verarbeitung der Anforderungen die Wartezeit überschritten wird, müssen Sie möglicherweise die Anzahl der verfügbaren Instanzen oder die Art und Weise, wie Anwendungen diese Instanzen nutzen, anpassen.

Berücksichtigen Sie außerdem, wie lange die Benutzer jeweils die Services verwenden. Einige Anforderungen an den Server sind arbeitsintensiver als andere. Eine große Anzahl von einfachen Service-Anforderungen ist für den Server möglicherweise nicht so schwierig zu verarbeiten wie eine kleinere Anzahl von arbeitsintensiven Anforderungen. Jeder Service verfügt über eine Eigenschaft zur Festlegung der maximalen Wartezeit und eine Eigenschaft zur Festlegung der maximalen Verwendungszeit. Wenn die Wartezeit von Service-Anforderungen der Benutzer immer wieder überschritten wird, sollten Sie in Betracht ziehen, die maximale Wartezeit oder die Anzahl der verfügbaren Instanzen des Service zu erhöhen.

Wenn Sie die Anzahl der Instanzen ermittelt haben, die die Clients unterstützen sollen, teilen Sie diese durch die Anzahl der ArcGIS Server-Computer in der Bereitstellung und legen die Höchstzahl der Instanzen für die Service-Konfiguration auf das Ergebnis fest. Wenn Sie beispielsweise maximal zehn Instanzen eines Service für die gleichzeitige Verarbeitung der Anforderungen benötigen und zwei ArcGIS Server-Computer verfügbar sind, legen Sie die Höchstzahl der Instanzen auf fünf fest.

Jede Instanz belegt Speicherplatz, auch wenn der Service nicht verwendet wird. Wenn Sie die Mindestanzahl der Instanzen pro Computer unter der maximalen Anzahl der Instanzen pro Computer festlegen, können Sie nicht verwendeten Speicher freigeben. Diese Funktion hat in der Regel nur geringe Auswirkungen auf die Performance. Bei dem Starten neuer Instanzen kann es zu Verzögerungen bei den Anforderungen kommen. Um diese Verzögerung zu vermeiden, können Sie die Mindestanzahl an Instanzen pro Computer auf die maximale Anzahl an Instanzen pro Computer festlegen.

Ermitteln Sie anhand der Protokolle und der Serverstatistiken, ob zu viele Anforderungen Wartezeitüberschreitungen verursachen und ob Services über ihre maximale Verwendungszeit hinaus verwendet werden. Passen Sie über Server Manager die Anzahl der verfügbaren Service-Instanzen und die maximale Warte- und Verwendungszeit für einen Service an.

Pooling von Service-Instanzen

Sämtliche mit ArcGIS Server veröffentlichten Services befinden sich in einem Pool. Das heißt, dass Instanzen des Service mehrere Anwendungssitzungen unterstützen.

Eine Anwendung, die eine Instanz eines in einem Pool befindlichen Services verwendet, verwendet diese nur für die Dauer, die für das Abschließen einer Anforderung erforderlich ist (z. B. zum Zeichnen einer Karte oder für die Geokodierung einer Adresse). Nachdem die Anforderung abgeschlossen wurde, gibt die Anwendung den entsprechenden Verweis wieder für den Service frei und gibt die Instanz direkt an den verfügbaren Instanzen-Pool zurück.

Recycling von Service-Instanzen

Durch das Recycling von Services können nicht mehr verwendbare Services gelöscht und mit neuen Services ersetzt werden. Die von dem veralteten Service benötigten Ressourcen werden so außerdem wieder freigegeben.

Services werden in der Regel von mehreren Anwendungen und deren Benutzern gemeinsam verwendet. Durch diese Wiederverwendung können die Services so beeinflusst werden, dass sie von den Anwendungen nicht mehr verwendet werden können. Eine Anwendung kann beispielsweise den Status eines Services ändern oder einen Verweis auf einen Service belegen, sodass dieser für andere Anwendungen oder Sitzungen nicht mehr verfügbar ist. In einigen Fällen werden Services beschädigt oder unbrauchbar. Durch das Recycling können Sie die Aktualität des Service-Pool gewährleisten und veraltete oder nicht mehr verwendbare Services ausmustern.

Während des Recycling-Vorgangs löscht der Server sämtliche Instanzen in der Service-Konfiguration, und erstellt diese anschließend neu. Das Recycling erfolgt als Hintergrundprozess auf dem Server. Obwohl auf dem Bildschirm nichts auf den Recycling-Vorgang hindeutet, werden die mit dem Recycling verbundenen Ereignisse in den Protokolldateien angezeigt.

Beim Recycling werden alle ausgeführten Instanzen eines Services gelöscht und neu erstellt, unabhängig davon, ob die Instanzen die angegebene Mindestanzahl überschreiten oder nicht. Um die Anzahl der ausgeführten Instanzen in regelmäßigen Abständen auf die angegebene Mindestanzahl zurückzusetzen, muss der Service beendet und neu gestartet werden. Eine gute Möglichkeit, diesen Prozess zu automatisieren, besteht darin, ein Python-, Shell- oder Windows-Batch-Skript zu erstellen, das eine benutzerdefinierte ausführbare Datei mit einer ArcGIS Server-Verwaltungs-API-Befehlszeile ausführt. In dieser benutzerdefinierten ausführbaren Datei wird in Form von Befehlszeilenargumenten der Servername, Service-Name und Service-Typ angegeben sowie, ob der Service gestartet oder angehalten werden soll.

Die Zeit zwischen den Recycling-Ereignissen wird als Recycling-Intervall bezeichnet. Das standardmäßige Recycling-Intervall beträgt 24 Stunden und kann im Dialogfeld Service-Editor angepasst werden. Sie können auch den Zeitpunkt auswählen, zu dem erstmalig ein Recycling für die Konfiguration erfolgen soll. Ab diesen Zeitpunkt erfolgt das Recycling jeweils nach Ablauf des Recycling-Intervalls.

Beim Recycling von Services wird immer nur auf eine Instanz zugegriffen, damit Instanzen verfügbar bleiben, und um die Beeinträchtigung der Leistung, die die Erstellung neuer Instanzen für sämtliche Services mit sich bringt, zu verteilen. Das Recycling erfolgt in zufälliger Reihenfolge; Instanzen von Services, die jedoch gerade von Clients verwendet werden, werden erst recycelt, nachdem sie freigeben wurden. Auf diese Weise erfolgt das Recycling, ohne dass die Verwendung eines Services unterbrochen wird.

Wenn während eines Recycling-Vorgangs nicht genügend Instanzen verfügbar sind, wird eine Anforderungen in die Warteschlange gestellt, bis eine Instanz verfügbar ist. Wenn die maximale Wartezeit des Service während dieser Zeit erreicht wird, zeichnen die Protokolle die gleiche Meldung auf, die sie auch normalerweise protokollieren würden.

Überprüfen auf ungültige Datenverbindungen

Wenn sich eine Service-Instanz im Leerlauf befindet, kann ein Serveradministrator nur mit Mühe feststellen, ob die Verbindungen zu den Quelldaten beibehalten werden. ArcGIS Server verfügt über integrierte Mechanismen, mit denen ungültige Verbindungen zu Enterprise-Geodatabases ermittelt werden können. Durch diese Prüfungen wird verhindert, dass der Service nicht reagiert, nachdem eine Verbindung zur Datenbank beendet oder unterbrochen wurde.

Hinweis:

Die Unterstützung für die Überprüfung auf ungültige Datenverbindungen umfasst keine File-Geodatabases.

Sie können die Gültigkeitsprüfungen für Datenverbindungen aktivieren, indem Sie die Registerkarte Prozesse im Dialogfeld Service-Editor in ArcGIS Server Manager öffnen und das Kontrollkästchen Datenverbindungen regelmäßig auf Leerlaufinstanzen überprüfen und reparieren aktivieren. Sie müssen auch ein Intervall in Minuten festlegen, nach dem Service-Verbindungen automatisch überprüft (und ggf. repariert) werden. Der Standardwert von 30 Minuten ist normalerweise geeignet.

Das Aktivieren dieser Prüfungen kann auch hilfreich sein, wenn Firewalls Ports zu Enterprise-Geodatabases schließen, nachdem sich die Services für einen bestimmten Zeitraum im Leerlauf befunden haben. In dieser Situation kann es ratsam sein, sich beim Auswählen des Wertes für das Zeitintervall nach den Timeout-Einstellungen der Firewall zu richten.

Timeouts

Die Kenntnis der verschiedenen verfügbaren Service-Timeout-Werte kann hilfreich sein, um das Funktionieren und die Verfügbarkeit der Services sicherzustellen. Diese Werte sind auf der Registerkarte Pooling des Dialogfeldes Service-Editor aufgelistet.

Sobald ein Client einen Verweis auf einen Service abruft, verwendet er den Service für einen bestimmten Zeitraum, bevor er ihn wieder freigibt. Die Zeit zwischen dem Empfang eines Verweises auf einen Service durch einen Client und der Freigabe des Services wird als Verwendungszeit bezeichnet. Um sicherzustellen, dass Clients Verweise auf Services nicht zu lange belegen (d. h. dass die Services nicht ordnungsgemäß freigegeben werden), können Sie für jeden Service eine maximale Zeit, die ein Client einen Service verwenden kann, konfigurieren. Wenn ein Service von einem Client länger als diese maximale Verwendungszeit belegt wird, wird der Service automatisch freigegeben. Der Client verliert in diesem Fall den Verweis auf den Service.

Tauchen Sie ein:

Beim Erstellen eines neuen Service beträgt der Standardwert für die maximale Verwendungszeit 600 Sekunden (10 Minuten). In dem vorgenerierten PublishingTools-Service, über den jede ArcGIS Server-Site verfügt, ist die maximale Verwendungszeit jedoch auf 3600 Sekunden (60 Minuten) festgelegt. Dies dient der bestmöglichen Erfüllung von Veröffentlichungen, bei denen große Datenmengen auf den Server kopiert werden.

Zudem verhindert die maximale Verwendungszeit, dass Services zur Bearbeitung eines größeren Arbeitsaufkommen als vom Administrator gewünscht verwendet werden. Ein Service, der von einer Anwendung für Geodatabase-Auscheckvorgänge verwendet wird, kann beispielsweise eine maximale Verwendungszeit von zehn Minuten haben. Ein Service mit einem Layer, der lediglich zum Zeichnen von Karten in einer Anwendung verwendet wird, hätte hingegen eine Verwendungszeit von nicht mehr als einer Minute.

Wenn die maximale Anzahl der Instanzen eines Service verwendet wird, werden Clients, die einen Service anfordern, einer Warteschlange hinzugefügt, bis ein anderer Client einen der Services freigibt. Als Wartezeit wird hierbei die Zeit zwischen der Anforderung eines Services durch den Client und dem Erhalt des Services bezeichnet. Jeder Service verfügt über eine maximale Zeit, die ein Client auf einen Service wartet. Sollte die Wartezeit eines Clients für einen Service diesen Maximalwert übersteigen, überschreitet die Anforderung das Timeout.

Ein dritter Timeout-Wert bestimmt die maximale Zeit, die eine Leerlaufinstanz ausgeführt wird. Wenn Services nicht mehr verwendet werden, werden sie weiterhin auf dem Server ausgeführt, bis ein anderer Client die Instanz benötigt. Eine ausgeführte Instanz, die nicht verwendet wird, belegt aber dennoch einen gewissen Speicherplatz auf dem Server. Sie können die Anzahl der ausgeführten Services minimieren und damit Speicherplatz sparen, indem Sie das Leerlaufzeitlimit verkürzen, das standardmäßig 1.800 Sekunden (30 Minuten) beträgt. Der Nachteil eines kurzen Leerlaufzeitlimits besteht darin, dass, falls alle ausgeführten Services das Zeitlimit erreichen, nachfolgende Clients warten müssen, bis neue Instanzen erstellt werden.

Als Erstellungszeit wird die zur Initialisierung der Service-Instanz benötigte Zeit bezeichnet, wenn infolge eines Serverstarts oder einer Serveranforderung durch einen Client Service-Instanzen im GIS-Server erstellt werden. Am GIS-Server ist ein Start-Timeout festgelegt, das die maximale Zeit festlegt, in der ein Service gestartet werden muss. Andernfalls geht der GIS-Server davon aus, dass der Startvorgang nicht reagiert, und bricht die Erstellung der Service-Instanz ab. Der Standard ist 300 Sekunden (5 Minuten).

Der GIS-Server unterhält sowohl im Speicher als auch in den servereigenen Protokollen Statistiken zu Wartezeit, Verwendungszeit und anderen Ereignissen im Server. Der Serveradministrator kann anhand dieser Statistiken ermitteln, ob die Wartezeit für einen Service beispielsweise ungewöhnlich hoch ist. Dies kann darauf hinweisen, dass die maximale Anzahl von Instanzen für diesen Service erhöht werden sollte.

In Ihrer Architektur können zusätzliche Timeouts auftreten, die Diskrepanzen zwischen den von Ihnen angegebenen Service-Timeout-Werten und den tatsächlichen Timeouts bei Clients verursachen können. Der Webserver, auf dem ArcGIS Web Adaptor gehostet wird, oder ein Netzwerk-Load-Balancer kann Timeouts erzwingen, die sich auf Ihre Services auswirken.

Hinweis:

Wenn Ihre Site ein hohes Datenaufkommen aufweist, sind Diskrepanzen zwischen von Ihnen angegebenen Timeout-Werten und den Timeouts bei Clients zu erwarten.

Einschränken, welche Vorgänge Benutzer mit einem Service ausführen können

Damit sich die Verwendung der Web-Services leichter steuern lässt, sind für jeden Service-Typ verschiedene zulässige Vorgänge festgelegt. Jeder Vorgang besteht aus mehreren Methoden, die als Gruppe aktiviert bzw. deaktiviert werden können. Clients des Web-Services können nur die Methoden der zulässigen Vorgänge aufrufen.

Angenommen, Sie möchten, dass die Benutzer eines Kartenerstellungs-Services die Karte zwar zeichnen, aber die Datenquellen der Karten-Layer nicht abfragen können. Sie müssten die Datenoperation in diesem Fall deaktivieren und sicherstellen, dass die Kartenoperation zulässig ist.

Feature-Services sind hier von besonderem Interesse, weil sie zur web-basierten Bearbeitung von GIS-Daten verwendet werden. Feature-Services verfügen über einen zusätzlichen Satz von Operationen, der zum Beschränken der Bearbeitungsfunktionen verwendet werden kann. Sie können diese auf der Registerkarte Feature-Zugriff des Dialogfeldes Service-Editor in ArcGIS Server Manager aktivieren oder deaktivieren. Zudem können Sie Benutzer daran hindern, Features zu bearbeiten, die nicht von ihnen selbst erstellt wurden, indem Sie die besitzbasierte Zugriffssteuerung erzwingen.

Unter Typen von Services erfahren Sie mehr über die zulässigen Operationen für verschiedene Service-Typen.

Szenarien für das Optimieren von Services

Die folgenden Szenarien bieten einige praxisnahe Beispiele dafür, wie ein Administrator Services an die Bedürfnisse der Benutzer anpassen kann.

Szenario: langsame Reaktionszeit des Service

Eine Benutzerin in Ihrer Organisation hat ungewöhnlich und inakzeptabel lange Wartezeiten gemeldet, bis ein bestimmter Kartenservice angezeigt wird. Nach einigen Tests des Kartenservice entdecken Sie, dass die Darstellung eines Layers im Kartenservice ungewöhnlich lange dauert. Im Rahmen der weiteren Untersuchung befolgen Sie die Anweisungen unter Beheben von Problemen mit der Kartenservice-Performance durch Serverprotokolle und isolieren Informationen zum Kartenservice.

Potenzielle Ursache 1

Anhand der Server Manager-Protokolle erkennen Sie übermäßig lange Darstellungszeiten für einen (oder mehrere) Layer im Service.

Allgemeine Lösungen für 1

Befolgen Sie die folgenden Best Practices, um die Performance der Karte zu optimieren:

  • Nutzen Sie maßstabsabhängiges Rendern.

  • Entfernen Sie nicht genutzte Layer und Datenrahmen.

  • Nutzen Sie Validierung für Definitionsabfragen.

  • Vereinfachen Sie die Layer-Symbolisierung.

  • Verwenden Sie wo möglich gecachte Karten (beispielsweise, wenn sich die Daten nur selten ändern).

Nach der Überprüfung des Service, der Umsetzung der Optimierungstipps und der erneuten Veröffentlichung des Service stellen Sie und Ihre Kollegin eine erhebliche Verbesserung bei der Reaktion des Kartenservice fest.

Potenzielle Ursache 2

Aus den Server Manager-Protokollen geht hervor, dass ein verzögerter Netzwerkzugriff auf einen Layer im Service dessen Performance beeinträchtigen könnte.

Allgemeine Lösungen für 2

Minimieren Sie anhand der folgenden Best Practices für Datenzugriff und -management die Netzwerklatenz, und optimieren Sie die Service-Performance:

Nach der Überprüfung des Service, der Umsetzung der Tipps für Datenzugriff und -management und der erneuten Veröffentlichung des Service stellen Sie und Ihre Kollegin eine erhebliche Verbesserung bei der Reaktion des Kartenservice fest.

Szenario: Sicherstellen ausreichender Computerressourcen

Sie haben eine äußerst gefragte Web-App entwickelt und möchten sie an einem bestimmten Datum Ende der Woche einem breiteren Publikum vorstellen. Da Sie eine große Anzahl von Anforderungen an die Services in der App erwarten, möchten Sie sicherstellen, dass Sie über angemessene Computerressourcen verfügen.

Um ausreichende Ressourcen auf dem Servercomputer für eine intensive Nutzung der Web-App bereitzustellen, überprüfen Sie die ArcGIS Server-Statistiken, um selten genutzte Services zu identifizieren und die Service-Eigenschaften für die Benutzer dieser App entsprechend anzupassen. Im Gegenzug passen Sie die Service-Eigenschaften für die Services in der Web-App entsprechend an.

Mögliche Lösung

Verwalten und optimieren Sie die Service-Eigenschaften, um Ressourcen für Ihre Site zuzuweisen. Berücksichtigen Sie beispielsweise, über welchen Zeitraum hinweg die Benutzer die Services verwenden. Wird die maximale Verwendungszeit überschritten? Treten aufgrund von übermäßigen Anfragen Timeouts auf?

Die folgenden Empfehlungen dienen als Anhaltspunkt für die Anpassung der Service-Eigenschaften zum Planen und Berücksichtigen von Benutzern:

  • Identifizieren Sie die am häufigsten verwendeten Services, und erhöhen Sie die minimale Anzahl an Instanzen für sie. Dadurch verringert sich die Wartezeit der Endbenutzer.

  • Migrieren Sie stattdessen Services unter Verwendung dedizierter Instanzen, die den Pool geteilter Instanzen nutzen können.

  • Erhöhen Sie wo nötig die minimale und maximale Anzahl an Instanzen, die Wartezeiten, Leerlaufzeit und Verwendungszeit, um Verzögerungen für die Endbenutzer zu reduzieren.

  • Verringern Sie wo nötig Instanzen, Wartezeit und Leerlaufzeit, um Systemressourcen für Services freizugeben, die sie dringender benötigen.