Pooling

Sämtliche mit ArcGIS 10.1 for Server und höheren Versionen 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.

Recyceln von

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 for 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 Services 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.

Isolation

Wenn Sie einen Service erstellen, geben Sie die minimale und maximale Anzahl an Instanzen an, die Sie zur Verfügung stellen möchten. Diese Instanzen werden auf den Container-Computern in Prozessen ausgeführt. Der Isolationsgrad bestimmt, ob die Instanzen in separaten oder in gemeinsam verwendeten Prozessen ausgeführt werden.

Bei einer hohen Isolation wird jede Instanz in einem eigenen Prozess ausgeführt. Wenn im Prozess ein Fehler auftritt, ist bei dieser Einstellung nur die eine Instanz betroffen, die darin ausgeführt wird.

Im Gegensatz dazu, können bei einem niedrigen Isolationsgrad mehrere Instanzen einer Service-Konfiguration einen Prozess gemeinsam nutzen. Auf diese Weise kann ein Prozess mehrere voneinander unabhängige Anforderungen gleichzeitig verarbeiten. Dies wird oft als Multi-Threading bezeichnet.

Bei einer niedrigen Isolation können standardmäßig 8 und maximal 24 Instanzen derselben Service-Konfiguration einen Prozess gemeinsam verwenden. Sie können den Wert für Instanzen pro Prozess auf der Registerkarte Prozesse im Service-Editor festlegen. Wenn die angegebene Anzahl von Instanzen eines bestimmten Services erstellt wurde, startet der Server einen zusätzlichen Prozess für die nächste Gruppe von Instanzen usw. Da Instanzen erstellt und wieder gelöscht werden, geben Sie in diesen ausgeführten Prozessen entweder Platz frei oder belegen Platz.

Der niedrige Isolationsgrad ist insofern von Vorteil, als dadurch die Anzahl an Instanzen, die von einem Prozess gleichzeitig unterstützt werden, steigt. Durch die Verwendung der niedrigen Isolation wird etwas weniger Speicher auf dem Server belegt. Diese Verbesserung birgt jedoch auch Risiken. Wenn ein Prozess heruntergefahren wird oder abstürzt, werden alle Instanzen, die den Prozess verwenden, gelöscht. Daher wird dringend empfohlen, eine hohe Isolation zu verwenden.

Ü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 for Server verfügt über integrierte Mechanismen, mit denen ungültige Verbindungen zu Enterprise-, Workgroup- oder Desktop-Geodatabase-Geodatabases ermittelt werden können. Durch diese Prüfungen wird verhindert, dass der Service nicht reagiert, nachdem eine Verbindung zu Enterprise-, Workgroup- oder Desktop-Geodatabase beendet oder unterbrochen wurde.

Sie können die Gültigkeitsprüfungen für Datenverbindungen aktivieren, indem Sie die Registerkarte Prozesse im Dialogfeld Service-Editor entweder in ArcGIS for Desktop oder 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 Standard von 30 Minuten ist normalerweise geeignet.

Das Aktivieren dieser Prüfungen kann auch hilfreich sein, wenn Firewalls Ports zu Enterprise-, Workgroup- oder Desktop-Geodatabase 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.

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.

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 for Desktop deaktivieren. Zudem können Sie Benutzer daran hindern, Features zu bearbeiten, die nicht von ihnen erstellt wurden, indem Sie die eigentumsbasierte Zugriffssteuerung erzwingen.

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