Optimieren und Konfigurieren von Services

ArcGIS for Desktop erleichtert die sofortige Veröffentlichung von Services, da viele der standardmäßigen Service-Eigenschaften bereits für Sie festlegt werden. Wenn jedoch Hunderte oder Tausende von Benutzern auf die Services zugreifen, sollten Sie die standardmäßigen Service-Eigenschaftswerte so ändern, dass sie die Anforderungen der Bereitstellung bestmöglich erfüllen. Dieses Thema bietet eine Übersicht über einige Eigenschaften und Methoden, mit denen Sie die Services optimal konfigurieren können.

Pooling

Sämtliche mit ArcGIS 10.1 for Server veröffentlichte 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 Service 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

Durch das Recycling von Services können nicht mehr verwendbare Services gelöscht und durch neue 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 Service ä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 Service 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 diesem 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 Performance, 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 Service 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.

Wenn Sie die einem Service zugrunde liegenden Daten ändern, wird diese Änderung nach dem Recycling automatisch widergespiegelt. Wenn Sie beispielsweise einen Karten-Service ausführen und das zugehörige Kartendokument ändern, so wird diese Änderung nach dem Recycling angezeigt. (Wenn Sie die Änderungen sofort wiedergeben möchten, müssen Sie den Service manuell anhalten und neu starten.)

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.

Services mit hoher Isolation werden in für sie reservierten Prozessen auf dem GIS-Server ausgeführt.

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 Dialogfeld Service-Editor festlegen. Wenn die angegebene Anzahl von Instanzen eines bestimmten Service 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 kann die Speicherauslastung auf dem Server bedeutend verbessert werden. Diese Verbesserung birgt jedoch auch Risiken. Wenn ein Prozess heruntergefahren wird oder abstürzt, werden alle Instanzen, die den Prozess verwenden, gelöscht.

Ü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. Der ArcGIS-Server verfügt über integrierte Mechanismen, mit denen ungültige Verbindungen zu ArcSDE-Geodatabases ermittelt werden können. Durch diese Prüfungen wird verhindert, dass der Service nicht reagiert, nachdem eine Verbindung zu ArcSDE 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 ArcCatalog oder Manager öffnen und das Kontrollkästchen Datenverbindungen für Instanzen im Leerlauf regelmäßig ü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 ArcSDE 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 Service 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.

Dive-in:

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 3.600 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, der von einer Anwendung zum Zeichnen von Karten verwendet wird, hätte hingegen eine Verwendungszeit von nur 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 Service durch den Client und dem Erhalt des Service 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 des Service benötigte Zeit bezeichnet, wenn infolge eines Serverstarts oder einer Serveranforderung durch einen Client Services 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 des Service ab.

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.

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-Service können nur die Methoden der zulässigen Vorgänge aufrufen.

Angenommen, Sie möchten, dass die Benutzer eines Web Mapping-Service die Karte zwar zeichnen, aber die Datenquellen der Karten-Layer nicht abfragen können. Sie müssten in diesem Fall die Abfrageoperation 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 Satz von Operationen, der zum Beschränken der Bearbeitungsfunktionen verwendet werden: Abfragen, Erstellen, Aktualisieren und Löschen. 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 besitzbasierte Zugriffssteuerung erzwingen.

Die folgende Tabelle enthält Methoden, die aktiviert werden, wenn Sie Operationen für verschiedene Service-Typen zulassen:

Karten-Service-Operationen

Die standardmäßig zulässigen Operationen für Karten-Services sind "Karte", "Abfrage" und "Daten".

Karte	Abfrage	Daten
GetDocumentInfo	Identifizieren	Finden
GetLegendInfo	QueryFeatureCount	QueryData
GetMapCount	QueryFeatureCount2	QueryFeatureData
GetMapName	QueryFeatureIDs	QueryFeatureData2
GetDefaultMapName	QueryFeatureIDs2	QueryAttachmentInfos
GetServerInfo	QueryHyperlinks	QueryAttachmentInfos2
GetSupportedImageReturnType	QueryHTMLPopups	QueryAttachmentData
ExportMapImage	QueryHTMLPopups2	QueryAttachmentData2
IsFixedScaleMap	GetSQLSyntaxInfo	QueryRelatedRecords
ToMapPoints		QueryRelatedRecords2
FromMapPoints		QueryRasterValue
HasSingleFusedMapCache		QueryRasterValue2
GetTileCacheInfo
GetMapTile
HasLayerCache
GetLayerTile
GetVirtualCacheDirectory
GetCacheName
ComputeScale
ComputeDistance
ExportScaleBar
GetCacheDescriptionInfo
GetCacheControlInfo
GetCacheStorageInfo
GetDefaultLayerDrawingDescriptions
GetMapTableSubtypeInfos
GetMapTableSubtypeInfos2
GetServiceConfigurationInfo

Geokodierungs-Service-Operationen

Die standardmäßig zulässigen Operationen für Geokodierungs-Services sind "Geokodierung" und "Rückwärts-Geokodierung".

Geokodierung	Rückwärts-Geokodierung
GeocodeAddress	ReverseGeocode
GeocodeAddresses
StandardizeAddress
FindAddressCandidates
GetAddressFields
GetCandidateFields
GetIntersectionCandidateFields
GetStandardizedFields
GetStandardizedIntersectionFields
GetResultFields
GetDefaultInputFieldMapping
GetLocatorProperties

Geodaten-Service-Operationen

Die standardmäßig zulässigen Operationen für Geodaten-Services sind "Abfrage" und "Extraktion". Diese Operationen ermöglichen alle unterstützten Methoden für die Abfrage und Extraktion von Daten. Die Operation "Replikation" ermöglicht alle unterstützten Methoden für die Synchronisation, Datenänderungen, Meldungsbestätigungen und Schemas.

Abfrage	Extraktion	Replikation
Get_Versions	ExpandReplicaDatasets	CreateReplica
Get_DefaultWorkingVersion	ExtractData	ExportAcknowledgement
Get_DataElements		ExportReplicaDataChanges
Get_MaxRecordCount		ImportAcknowledgement
TableSearch		ImportReplicaDataChanges
GetNextResultPortion		ReExportReplicaDataChanges
Get_Replicas		UnregisterReplica
Get_WrappedWorkspaceType		ImportData

Globe-Service-Operationen

Die standardmäßig zulässigen Operationen für Globe-Services sind "Globus", "Animation" und "Abfrage". Anders als bei Karten-Services deckt die Abfrageoperation sowohl "Identifizieren" als auch "Suchen" ab.

Globus	Animation	Abfrage
Get_Version	Get_Animation	Identifizieren
Get_LayerCount		Finden
Get_LayerInfos
Get_LegendInfos
Get_Config
Get_MQT
Get_Configuration
Get_Tile
Get_Symbols
Get_Textures
Get_VirtualCacheDirectory

Image-Service-Operationen

Wenn Sie den Image-Service aus einem Mosaik-Dataset veröffentlicht haben, werden alle Funktionen standardmäßig aktiviert. Wenn Sie den Service über eine andere Quelle veröffentlichen, beispielsweise über ein Raster-Dataset, eine kompilierte Image-Service-Definition oder eine Layer-Datei, sind nur die Funktionen für Bild und Metadaten verfügbar und aktiviert.

Bild	Katalog	Laden Sie	Metadaten	Pixel
ExportImage	Felder	Laden Sie	Metadaten	GetNativePixelBlock
ExportMapImage	GetCatalogItemCount	GetFile	GetRasterMetadata	GetPixelBlock
GenerateServiceInfo	GetCatalogItemIDs
GetImage	GetCatalogItems
Identifizieren	GetNativeRasterInfo
ServiceInfo	GetRasterInfo
Version	GetThumbnail