Optimieren und Konfigurieren von Services
ArcGIS Server 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 oder wenn Benutzer statusgesteuerte Vorgänge wie z. B. Bearbeitungen an den Services ausführen, sollten Sie die standardmäßigen Service-Eigenschaftswerte so ändern, dass sie Anforderungen Ihrer Bereitstellung bestmöglich erfüllen. Dieses Thema bietet eine Übersicht über einige Eigenschaften und den Techniken, mit denen Sie die Services optimal konfigurieren können.
Pooling
Sie können die Eigenschaften eines Services dahingehend ändern, dass er sich in einem Pool befindet oder dass er sich nicht in einem Pool befindet. Instanzen eines in einem Pool befindlichen Services unterstützen mehrere Anwendungssitzungen. Wenn eine Anwendungssitzung eine in einem Pool befindliche Service-Instanz an den Server zurückgibt, ist diese auch für die Verwendung durch andere Anwendungssitzungen verfügbar. Daher sollten in einem Pool befindliche Services nur mit statusunabhängigen Operationen verwendet werden.
Im Gegensatz dazu sind Instanzen eines nicht in einem Pool befindlichen Services auf nur eine Anwendungssitzung ausgerichtet. Eine Instanz eines nicht in einem Pool befindlichen Services wird gelöscht, wenn sie von einer Anwendungssitzung an den Server zurückgegeben wird. Nicht in einem Pool befindliche Services werden verwendet, wenn die Anwendung statusbezogene Operationen ausführen muss, z. B. das Bearbeiten mit aktivierten Rückgängig-/Wiederholen-Funktionen.
Sowohl bei Konfigurationen mit in einem Pool befindlichen Services als auch bei Konfigurationen mit nicht in einem Pool befindlichen Services müssen Sie eine maximale sowie eine minimale Anzahl an Instanzen angeben, wenn Sie den Service hinzufügen. Wenn Sie die Service-Konfiguration beginnen, erstellt und initialisiert der GIS-Server die angegebene minimale Anzahl an Instanzen. Wenn eine Anwendung beim Server Object Manager (SOM) eine Instanz eines Services anfordert, erhält sie einen Verweis auf eine der Instanzen. Wenn alle Instanzen gerade verwendet werden, erstellt der Server eine neue Instanz. Dieser Vorgang wird für sämtliche hierauf folgenden Anforderung wiederholt, bis die maximal zulässige Zahl von Instanzen für die Konfiguration erreicht wurde oder bis die Kapazität aller Container-Computer erreicht wurde, je nachdem, welches Limit zuerst erreicht wird.
In einem Pool befindliche Services
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. Benutzer einer solchen Anwendung arbeiten möglicherweise mit mehreren verschiedenen Instanzen eines Services im Pool, die mit der Anwendung interagieren. Dies ist für den Benutzern erkennbar, da alle Instanzen im Pool denselben Status aufweisen.
Zum Beispiel ruft eine statusunabhängige Anwendung, die einen bestimmten Anteil einer Karte zeichnen soll, einen Verweis für eine Instanz eines Karten-Services aus dem Pool ab, führt eine Methode auf den Karten-Service aus, um die Karte zu zeichnen, und gibt den Verweis anschließend wieder im Pool frei. Wenn die Anwendung die Karte wieder zeichnen möchte, wird dieser Vorgang wiederholt. Für jedes Zeichnen der Karte wird möglicherweise eine andere Instanz aus dem im Pool befindlichen Service verwendet; demzufolge müssen die Instanzen einander entsprechen (über denselben Satz von Layern verfügen, dieselben Renderer für die einzelnen Layer verwenden usw.) Wenn Sie den Status einer Instanz ändern, z. B. wenn Sie einen Layer hinzufügen oder den Renderer eines Layers ändern, erhält der Benutzer unstimmige Ergebnisse, wenn er die Karte schwenkt oder ihre Größe durch Zoomen ändert. Dies liegt daran, dass die Instanz, deren Status geändert wurde, an den Pool zurückgegeben wurde. Es kann jedoch nicht garantiert werden, dass Benutzer, jedes Mal, wenn Sie einen Service anfordern, genau diese Instanz erhalten. Es liegt in der Verantwortung des Entwicklers, sicherzustellen, dass die Anwendung den Status der Instanz nicht ändert und dass die Instanz zeitnah an den Pool zurückgegeben wird.
Durch das Zusammenlegen von Services in einem Pool kann der GIS-Server eine größere Anzahl von Benutzern unterstützen, da weniger Ressourcen für einen bestimmten Service reserviert werden. Da Anwendungen einen Instanzen-Pool gemeinsam verwenden können, ist hier eine höhere Anzahl gleichzeitiger Benutzer auf dem System möglich, als dies der Fall wäre, wenn jeder Benutzer über einen Verweis für eine ihm vorbehaltene Instanz verfügen würde.
 |
In einem Pool befindliche Services unterstützen eine höhere Anzahl an Benutzern, da Anwendungssitzungen eine Sammlung von Services im Pool gemeinsam verwenden. |
Nicht in einem Pool befindliche Services
Eine Anwendung, die nicht in einem Pool befindliche Service-Instanzen nutzt, belegt den Verweis auf die entsprechende Instanz normalerweise für die Dauer Anwendungssitzung. Wenn die Anwendung die Instanz freigibt, wird diese entfernt, und der GIS-Server erstellt eine neue Instanz, um die Anzahl der verfügbaren Instanzen beizubehalten. Aus diesem Grund kann der Benutzer eines nicht in einem Pool befindlichen Services Änderungen an den dem Service zugrunde liegenden Daten vornehmen.
Bei nicht in einem Pool befindlichen Services darf die Korrelation zwischen der Anzahl der Benutzer auf dem System und der Anzahl der ausgeführten Service-Instanzen nicht vom Verhältnis 1:1 abweichen. Daher ist die Anzahl der gleichzeitigen Benutzer, die der GIS-Server unterstützen kann, gleich der Anzahl der nicht in einem Pool befindlichen Instanzen, die effektiv zu einem beliebigen Zeitpunkt unterstützt werden können.
 |
Damit möglichst viele gleichzeitige Benutzer von Ihrem GIS-Server unterstützt werden, sollten Sie die Verwendung von nicht in einem Pool befindlichen Services vermeiden und nur für statusbezogene Vorgänge, wie zum Beispiel die Webbearbeitung versionierter Daten in Betracht ziehen. Wenn Sie Anwendungen mit nicht in einem Pool befindlichen Services entwickeln, sollten Sie darauf achten, dass Sie die Service-Instanzen löschen, wenn sie nicht mehr benötigt werden. Wenn Sie in Manager eine Webbearbeitungsanwendung erstellen, die nicht in einem Pool befindliche Services verwendet, sollten Sie den Benutzern empfehlen, beim Beenden der Anwendung auf den Link Schließen zu klicken. Dadurch wird sichergestellt, dass die nicht in einem Pool befindlichen Service-Instanzen sofort und nicht erst nach ihrem Ablauf gelöscht werden.
Vorsicht:Verwenden Sie nicht in einem Pool befindliche Services nicht für ArcGIS Server Internet-Verbindungen. Verwenden Sie stattdessen lokale ArcGIS Server-Verbindungen.
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.
In einem Pool zusammengefasste 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. Beachten Sie, dass das Recycling für nicht in einem Pool befindliche Objekte nicht gilt, da diese explizit für die Verwendung durch einen bestimmten Client erstellt und nach der Verwendung entfernt werden.
Während des Recycling-Vorgangs löscht der Server sämtliche Instanzen in einer Konfiguration mit in einem Pool befindlichen Services, 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-API-Befehlszeile ausführt. In dieser benutzerdefinierten ausführbaren Datei wird in Form von Befehlszeilenargumenten der Servernamen, Service-Name und Service-Typ angegeben sowie, ob der Service gestartet oder angehalten werden soll. Die Implementierung erfolgt über IServerObjectAdmin.StartConfiguration und IServerObjectAdmin.StopConfiguration.
Anzeigen von Beispielcode zum Beenden und Starten von Services
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-Eigenschaften 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 wird. Wenn der für MaximumWaitTime festgelegte Wert während dieser Zeit erreicht wird, zeichnen die Protokolldateien 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 können vier voneinander unabhängige Anforderungen gleichzeitig ausgeführt werden. Dies wird oft als Multi-Threading bezeichnet.
 |
Bei einer niedrigen Isolation können standardmäßig 8 und maximal 265 Instanzen derselben Service-Konfiguration einen Prozess gemeinsam verwenden. Sie können die Instanzen pro Prozess auf der Registerkarte Prozesse im Dialogfeld Service-Eigenschaften 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 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. Durch die Verwendung der niedrigen Isolation ist auch das Verkleinern von Pools weniger effektiv, da alle Instanzen in einem Prozess beendet werden müssen, damit der Prozess zur Verkleinerung eines Pools entfernt werden kann.
Beachten Sie, dass nicht in einem Pool befindliche Services immer in eigenen Prozessen ausgeführt werden und deshalb kein Isolationsgrad gilt.
Ü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 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-Eigenschaften 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.
Detailinformationen:Standardmäßig führt ArcGIS Server bereits Prüfungen auf ausgelasteten Services aus, um Datenverbindungen zu überprüfen und zu reparieren. Alle 5 Minuten wird auf die jeweils nächste von einem Service empfangene Anforderung eine Prüfung ausgeführt. Sie können das Intervall ändern oder dieses Verhalten deaktivieren indem Sie das ConnectionCheckInterval-Tag zum Abschnitt<Eigenschaften> der Service-Konfigurationsdatei hinzufügen. Unter Service-Konfigurationsdateien erhalten Sie weitere Informationen zu ConnectionCheckInterval.
ConnectionCheckInterval kann keine Datenverbindungen für Services überprüfen, die sich im Leerlauf befinden.
Timeouts
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, für die ein Client den 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, 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 Services (egal ob aus einem Pool oder nicht) 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 Zeitlimit (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 Services 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 Services ab. Diese Eigenschaft kann nur durch die manuelle Bearbeitung der Service-Konfigurationsdatei geändert werden.
Der GIS-Server unterhält sowohl im Speicher als auch in den servereigenen Protokolldateien 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.
Beschränken der Serverlast mithilfe der Kapazitätseigenschaft
Durch die Kapazität wird die Anzahl der Service-Instanzen eingeschränkt, die auf einem SOC-Computer (Server Object Container) ausgeführt werden können. Standardmäßig ist die Kapazität uneingeschränkt. Wenn der Arbeitsspeicher auf Ihrem Computer jedoch limitiert ist, können Sie ein Kapazitätslimit festlegen, um sicherzustellen, dass der Speicherbedarf der ausgeführten Instanzen die Kapazität des Computers nicht überlastet.
Sobald die Anzahl der ausgeführten Service-Instanzen auf einem SOC-Computer diese Kapazität erreicht, erstellt der Server auf diesem Computer keine neuen Instanzen mehr. Wenn auf allen SOC-Computern das Kapazitätslimit erreicht wurde, wird mit dem Verkleinern der Pools begonnen.
Verwechseln Sie bei der Auswahl der Kapazitätswerte ausgeführte Instanzen nicht mit gerade verwendeten Instanzen. Ausgeführte Instanzen belegen zwar Speicher, benötigen aber keine CPU-Leistung. Instanzen, die gerade verwendet werden, verbrauchen Speicherplatz und CPU-Leistung. Ein Server, der nur vier gleichzeitig verwendete Instanzen unterstützt, kann möglicherweise weit mehr als vier ausgeführte Instanzen unterstützten, sofern der verfügbare Arbeitsspeicher ausreicht. Möglicherweise möchten Sie, dass diese Instanzen ausgeführt werden, damit sie jederzeit sofort verfügbar sind.
Wenn auf dem Computer viel Arbeitsspeicher verfügbar ist, sollten Sie die Kapazitätsoption Unbegrenzt beibehalten.
Detailinformationen:Der Server führt immer einen zusätzlichen ArcSOC.exe-Prozess im Hintergrund aus, der die Verwendung von Serververzeichnissen verwaltet. Dieser Prozess wird bei der Ermittlung der Kapazität nicht berücksichtigt.
Anpassung des Servers an die Nachfrage: Verkleinern von Pools
Was geschieht, wenn auf allen Container-Computern eines GIS-Servers die Kapazitäten ausgelastet sind? ArcGIS Server nutzt das Konzept der Poolverkleinerung, bei der Service-Instanzen der weniger gängigen Konfigurationen durch Instanzen der gängigeren Konfigurationen ersetzt werden.
Die Poolverkleinerung findet statt, wenn die Anzahl der ausgeführten Service-Instanzen das Kapazitätslimit auf sämtlichen SOC-Computern erreicht hat. Wenn dies der Fall ist und der SOM eine Anforderung für einen Service empfängt, erstellt der Server die angeforderte Instanz und löscht eine Instanz der Service-Konfiguration, die am längsten nicht mehr verwendet wurde. Die folgenden Punkte erklären die Funktionen und die Einschränkungen für das Verkleinern von Pools genauer:
- Beim Verkleinern von Pools werden keine Instanzen von Services gelöscht, die zum gegebenen Zeitpunkt von einer Anwendung verwendet werden. Wenn die Kapazitäten auf allen SOCs erreicht sind und alle ausgeführten Serverobjektinstanzen verwendet werden, werden alle neuen Instanzenanforderungen in eine Warteschlange gestellt.
- Beim Verkleinern von Pools wird die Mindestanzahl von Instanzen, die Sie für Ihre Service-Konfiguration festlegen, berücksichtigt. Diese Mindestanzahl ausgeführter Instanzen für eine Konfiguration wird durch den Vorgang grundsätzlich nicht unterschritten.
- Das Verkleinern von Pools funktioniert mit in Pools befindlichen Services genauso wie mit Services, die sich nicht in einem Pool befinden.
- Das Verkleinern von Pools findet statt, nachdem Sie Kapazitätswerte für die einzelnen SOC-Computer auf Ihrem GIS-Server festgelegt haben.
- Der Vorgang ist bei Service-Konfigurationen mit niedriger Isolation weniger wirksam. Services mit niedriger Isolation können bis zu vier Instanzen innerhalb eines SOC-Prozesses gemeinsam verwenden. Da beim Verkleinerung von Pools Prozesse erstellt und gelöscht werden, wirkt sich der Vorgang bei der niedrigen Isolation auf alle vier Instanzen im entsprechenden Prozess aus. Schon wenn nur eine dieser Instanzen zum entsprechenden Zeitpunkt verwendet wird, kann die Poolverkleinerung nicht durchgeführt werden.
- Durch das Verkleinern von Pools können bei einer hohen Belastung des Servers begrenzte Arbeitsspeicherressourcen besser genutzt werden. Wenn der Vorgang jedoch regelmäßig ausgeführt wird, sollten Sie das System ggf. mit zusätzlicher Hardware ausstatten. Durch sorgfältig gewählte Programmiermethoden und eine Optimierung der Service-Eigenschaften können Sie die Belastung des Servers zusätzlich reduzieren.
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ässigen Vorgängen 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 können, 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.
Wenn Sie mithilfe des Assistenten Neuen Service hinzufügen (anstelle des Assistenten GIS-Ressource veröffentlichen) einen Service erstellen, können Sie bereits bei der Erstellung des Service die zulässigen Operationen auswählen. Unabhängig davon, wie Sie den Service ursprünglich erstellt haben, können Sie die zulässigen Operationen eines vorhandenen Services durch Bearbeitung der Service-Eigenschaften ändern. Die verfügbaren Operationen sind auf der Registerkarte Funktionen des Dialogfeldes Service-Eigenschaften aufgelistet.
Die folgenden Tabellen enthalten die in den jeweiligen Operationen enthaltenen Methoden:
Karten-Service-Operationen
|
Karte |
Abfrage |
Daten |
|---|---|---|
|
GetDocumentInfo |
Identifizieren |
Suchen |
|
GetLegendInfo |
QueryFeatureCount |
QueryFeatureData |
|
GetMapCount |
QueryFeatureIDs |
|
|
GetMapName |
QueryHyperlinks |
|
|
GetDefaultMapName |
GetSQLSyntaxInfo |
|
|
GetServerInfo |
||
|
GetSupportedImageReturnType |
||
|
ExportMapImage |
||
|
IsFixedScaleMap |
||
|
ToMapPoints |
||
|
FromMapPoints |
||
|
HasSingleFusedMapCache |
||
|
GetTileCacheInfo |
||
|
GetMapTile |
||
|
HasLayerCache |
||
|
GetLayerTile |
||
|
GetVirtualCacheDirectory |
||
|
GetCacheName |
||
|
ComputeScale |
||
|
ComputeDistance |
Die standardmäßig zulässigen Operationen für Karten-Services sind "Karte", "Abfrage" und "Daten".
Geokodierungs-Service-Operationen
|
Geokodierung |
Rückwärts-Geokodierung |
|---|---|
|
GeocodeAddress |
ReverseGeocode |
|
GeocodeAddresses |
|
|
StandardizeAddress |
|
|
FindAddressCandidates |
|
|
GetAddressFields |
|
|
GetCandidateFields |
|
|
GetIntersectionCandidateFields |
|
|
GetStandardizedFields |
|
|
GetStandardizedIntersectionFields |
|
|
GetResultFields |
|
|
GetDefaultInputFieldMapping |
|
|
GetLocatorProperties |
Die standardmäßig zulässigen Operationen für Geokodierungs-Services sind "Geokodierung" und "Rückwärts-Geokodierung".
Geodaten-Service-Operationen
|
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 |
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.
Globe-Service-Operationen
|
Globus |
Animation |
Abfrage |
|---|---|---|
|
Get_Version |
Get_Animation |
Identifizieren |
|
Get_LayerCount |
Suchen |
|
|
Get_LayerInfos |
||
|
Get_LegendInfos |
||
|
Get_Config |
||
|
Get_MQT |
||
|
Get_Configuration |
||
|
Get_Tile |
||
|
Get_Symbols |
||
|
Get_Textures |
||
|
Get_VirtualCacheDirectory |
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.
Image-Service-Operationen
Bild | Katalog | Download | Metadaten | Pixel |
|---|---|---|---|---|
ExportImage | Felder | Download | Metadaten | GetNativePixelBlock |
ExportMapImage | GetCatalogItemCount | GetFile | GetRasterMetadata | GetPixelBlock |
GenerateServiceInfo | GetCatalogItemIDs | |||
GetImage | GetCatalogItems | |||
Identifizieren | GetNativeRasterInfo | |||
ServiceInfo | GetRasterInfo | |||
Version | GetThumbnail |
Wenn Sie den Image-Service in einem Mosaik-Dataset veröffentlichten, 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.