Ajustar y configurar servicios
ArcGIS Server facilita la publicación de servicios directos ya que establece muchas de las propiedades predeterminadas del servicio, sin embargo, si hay cientos de miles de usuarios accediendo a los servicios o si los usuarios realizan operaciones con estados, como por ejemplo, la edición de servicios, se recomienda que cambie los valores predeterminados de las propiedades del servicio para que se ajusten mejor a la implementación. Este tema ofrece una vista general de algunas de las propiedades y técnicas que puede utilizar para configurar sus servicios de una forma más óptima.
Agrupar
Puede modificar las propiedades de un servicio para convertirlas en agrupadas o no agrupadas. Las instancias de un servicio agrupado se pueden compartir entre varias sesiones de aplicación. Cuando la sesión de una aplicación devuelve una instancia de servicio agrupado al servidor, significa que está disponible para utilizar en otras sesiones de la aplicación. Por tanto, los servicios agrupados únicamente se deben utilizar con operaciones sin estado.
En cambio, las instancias de un servicio no agrupado se adaptan a la sesión de la aplicación. Una instancia de un servicio no agrupado se destruye cuando una sesión de aplicación la devuelve al servidor. Los servicios no agrupados se utilizan cuando sea necesario que la aplicación realice operaciones con estado, como por ejemplo, editar con la función deshacer/hacer habilitada.
Ambas configuraciones requieren que se especifique un número mínimo y máximo de instancias cuando se agrega el servicio. Cuando inicie la configuración del servicio, el servidor SIG crea e inicializa el número mínimo de instancias. Cuando una aplicación solicita al administrador de objetos de servidor (SOM) una instancia de ese servicio, obtiene una referencia a una de las instancias. Si todas las instancias están en uso, el servidor creará una nueva instancia. Esto se realizará en cada solicitud posterior hasta alcanzar el número máximo permitido de instancias para la configuración o hasta alcanzar la capacidad de todos los equipos de contenedor, lo que ocurra primero.
Servicios agrupados
Una aplicación que utiliza una instancia de un servicio agrupado lo utiliza únicamente durante el tiempo que tarda en completar una solicitud (por ejemplo, para trazar un mapa o geocodificar una dirección). Después de completar la solicitud, la aplicación libera su referencia en el servicio y la devuelve directamente al grupo de instancias disponibles. Los usuarios de dicha aplicación pueden trabajar con varias instancias diferentes de un servicio del grupo mientras interactúan con la aplicación. Los usuarios conocen este hecho, dado que el estado de todas las instancias en el grupo es el mismo.
Por ejemplo, una aplicación sin estado con la que se desee trazar una determinada extensión de un mapa obtendrá una referencia a una instancia de un servicio de mapas procedente del grupo, ejecutará un método en el servicio de mapas para trazar el mapa y, a continuación, liberarlo en el servicio. Siempre que sea necesario que la aplicación trace el mapa, se repite este proceso. Cada trazado del mapa puede utilizar una instancia diferente del servicio agrupado; por tanto, cada instancia debe ser la misma (tener el mismo conjunto de capas, el mismo renderizador para cada capa, etc.). Si cambia el estado de una instancia agregando, por ejemplo, una capa o cambiando un renderizador de capa, el usuario verá resultados con incoherencias cuando realice el desplazamiento panorámico o haga zoom en el mapa. Esto se debe a que la instancia, cuyo estado se ha cambiado, se ha devuelto al grupo y no se puede garantizar a los usuarios que recibirán esa instancia determinada procedente del grupo cada vez que se solicite un servicio. El desarrollador deberá asegurar que la aplicación no cambia el estado de la instancia y que la instancia se devuelve al grupo de forma apropiada.
Con los servicios agrupados, el servidor SIG puede admitir más usuarios con pocos recursos situados en un servicio particular. Dado que las aplicaciones pueden compartir un grupo de instancias, el número de usuarios que utilicen el sistema de forma simultánea puede ser mayor que el que sería posible si cada usuario mantuviera una referencia a una instancia adaptada.
 |
Los servicios agrupados pueden admitir más usuarios ya que las sesiones de aplicación comparten un conjunto de servicios en el grupo. |
Servicios no agrupados
Una aplicación que utiliza una instancia de servicio no agrupada generalmente hace referencia a la instancia durante el tiempo que dura la sesión de la aplicación. Cuando la aplicación libera la instancia, se destruye y el servidor SIG crea una nueva para mantener el número de instancias disponibles. Por esta razón, el usuario de un servicio no agrupado puede hacer cambios en los datos subyacentes del servicio.
Con los servicios no agrupados, el número de usuarios en el sistema no puede tener más que una correlación 1:1 con el número de instancias de servicio en ejecución. Por tanto, el número de usuarios simultáneos que puede admitir el servidor SIG es igual al número de instancias no agrupadas que éste puede admitir con eficacia en cualquier momento.
 |
Para lograr el mayor número posible de usuarios simultáneos en el servidor SIG, evite utilizar los servicios no agrupados a menos que los necesite para las operaciones con estados, como por ejemplo, la edición Web de los datos versionados. Cuando desarrolle aplicaciones con servicios no agrupados, asegúrese de destruir las instancias de servicios que ya no sean necesarias. Si crea una aplicación de edición Web en Administrador que utiliza servicios no agrupados, pida a los usuarios que hagan clic en el vínculo Cerrar cuando salgan de la aplicación. De este modo las instancias de servicio no agrupadas se destruirán inmediatamente y no cuando caduquen.
Precaución:Nunca utilice servicios no agrupados con las conexiones de Internet de ArcGIS Server. En su lugar, utilice las conexiones locales de ArcGIS Server.
Reciclaje
Con el reciclaje del servicio se pueden eliminar los servicios que han quedado inutilizables y su sustitución por servicios nuevos, además de solicitar los recursos empleados por servicios obsoletos.
Los servicios agrupados suelen compartirse entre varias aplicaciones y sus usuarios. La reutilización puede provocar que determinados servicios no estén disponibles para las aplicaciones. Por ejemplo, una aplicación podría de forma incorrecta modificar el estado de un servicio o retener la referencia de un servicio, lo que provocaría que no estuviera disponible para otras aplicaciones o sesiones. En determinados casos, los servicios podrían dañarse y quedar inutilizables. Con el reciclaje se mantiene el grupo de servicios actualizado y se eliminan del ciclo los servicios obsoletos o inutilizables. Tenga en cuenta que el reciclaje no se aplica a servicios no agrupados debido a que un determinado cliente los crea explícitamente y se destruyen tras su uso.
Durante el reciclaje, el servidor destruye y, después, vuelve a crear cada instancia utilizando la configuración de servicios agrupados. El reciclaje se produce como un proceso en segundo plano en el servidor. Aunque en la pantalla no aparece ningún mensaje que notifique la realización del reciclaje, puede ver los eventos asociados con el reciclaje en los archivos de registro.
El reciclaje destruye y vuelve a crear todas las instancias en ejecución de un servicio, independientemente de si esas instancias se encuentran o no por encima del mínimo especificado. Para devolver periódicamente el número de instancias en ejecución al mínimo especificado, el servicio deberá detenerse y reiniciarse. Para automatizar este proceso se puede crear una secuencia de comandos de lote de Windows, de capa o de Python que ejecute un archivo ejecutable de línea de comandos API de ArcGIS Server personalizado. Este archivo ejecutable personalizado tomará el nombre del servidor, el nombre del servicio, el tipo del servicio y si el servicio debe iniciarse o detenerse como argumentos de la línea de comandos. Se implementará con IServerObjectAdmin.StartConfiguration e IServerObjectAdmin.StopConfiguration.
Ver código de ejemplo para detener e iniciar servicios.
El tiempo transcurrido entre los eventos de reciclaje es el intervalo de reciclaje. El intervalo de reciclaje predeterminado es de 24 horas, que puede cambiar en el cuadro de diálogo Propiedades del servicio. También puede elegir la hora a la que se reciclará inicialmente la configuración. A partir de esa hora, el reciclaje se producirá cada vez que se alcance el intervalo de reciclaje.
Los servicios reciclan una instancia a la vez para garantizar que siempre hay instancias disponibles y para extender los accesos de rendimiento causados por la creación de una nueva instancia de cada servicio. El reciclaje se produce de forma aleatorio; sin embargo, las instancias de los servicios en uso por parte de los clientes no se reciclan hasta que se liberan. De esta forma, el reciclaje se produce sin tener que interrumpir al usuario de un servicio.
Si no hay suficientes servicios disponibles durante el reciclaje, se pondrá en cola una solicitud hasta que esté disponible una instancia. Si el conjunto de valores para MaximumWaitTime se alcanza durante este tiempo, los archivos de registro registrarán el mensaje habitual.
Si cambia los datos subyacentes de un servicio, este cambio se reflejará automáticamente después del reciclaje. Por ejemplo, si tiene un servicio de mapas en ejecución y cambia el documento de mapa asociado, podrá ver el cambio después de que se produzca el reciclaje. (Para ver los cambios inmediatamente, puede parar e iniciar el servicio manualmente).
Aislamiento
Al configurar un servicio, especifique el número de instancias mínimo y máximo que desee que estén disponibles. Estas instancias se ejecutan en los procesos de los equipos contenedores. El nivel de aislamiento determina si estas instancias se ejecutan en procesos independientes o compartidos.
Con un aislamiento alto, cada instancia se ejecuta en su propio proceso. Si el proceso falla solo afectará a la instancia en que se esté ejecutando.
 |
Los servicios con alto aislamiento se ejecutan en procesos adaptados en el servidor SIG. |
En cambio, el aislamiento bajo permite que varias instancias de una configuración de servicio compartan un solo proceso, de forma que pueden ejecutarse cuatro solicitudes independientes simultáneas. Esto se conoce como procesamiento múltiple.
 |
Con un aislamiento bajo, un valor predeterminado de 8 instancias y un valor máximo de 256 instancias de la misma configuración de servicios pueden compartir un proceso. Puede establecer las Instancias por proceso en la ficha Procesos del cuadro de diálogo Propiedades del servicio. Cuando se crea este número de instancias de un servicio particular, el servidor inicia un proceso adicional para el siguiente grupo de instancias, y así sucesivamente. A medida que las instancias se crean y se destruyen, vaciarán y rellenarán los espacios de esos procesos en ejecución.
La ventaja del aislamiento bajo es que aumenta el número de instancias simultáneas compatibles con un solo proceso. Utilizar un aislamiento bajo puede mejorar significativamente el consumo de memoria del servidor. Sin embargo, esta mejora implica cierto riesgo. Si durante la realización de un determinado proceso se produce un apagón o un fallo, todas las instancias implicadas en el proceso se destruirán. Un aislamiento bajo también reduce la efectividad del acortamiento de grupo ya que todas las instancias de un proceso deben quedar fuera de uso antes de que el acortamiento de grupo pueda eliminar el proceso.
Tenga en cuenta que los servicios no agrupados siempre ejecutan su propio proceso, por lo que no se aplica el nivel de aislamiento.
Buscar conexiones de datos no válidas
Cuando una instancia de servicio se encuentra inactiva, puede resultar difícil para un administrador del servidor determinar si las conexiones con los datos de origen se mantienen correctamente. ArcGIS Server tiene mecanismos integrados para comprobar las conexiones no válidas a las geodatabases de ArcSDE. Con estas comprobaciones se evita que el servicio deje de responder después de que una conexión con ArcSDE se elimine o se interrumpa.
Puede habilitar las comprobaciones de validez de la conexión de datos abriendo la ficha Procesos del cuadro de diálogo Propiedades del servicio en ArcCatalog o en Administrador, y marcando la casilla de verificación Comprobar periódicamente y reparar las conexiones de datos para instancias inactivas. También es necesario especificar un intervalo en minutos en el que se validarán automáticamente las conexiones de servicio (y se repararán si fuera necesario). El valor predeterminado de 30 minutos se considera adecuado.
Habilitar estas comprobaciones también le puede ayudar en el caso de que el firewall cierre los puertos en ArcSDE después de que los servicios permanezcan inactivos durante un determinado período de tiempo. En esta situación, la elección del intervalo de tiempo puede estar influenciada por los ajustes del tiempo de espera del firewall.
Explorar:Por defecto, ArcGIS Server realiza las comprobaciones en los servicios ocupados para validar y reparar las conexiones de datos. Cada 5 minutos, la siguiente solicitud recibida por un servicio da lugar a una comprobación. Puede cambiar el intervalo o deshabilitar su comportamiento agregando la etiqueta ConnectionCheckInterval a la sección <Properties> de archivos de configuración de servicios. Consulte los Archivos de configuración de servicios para obtener información adicional acerca de ConnectionCheckInterval.
ConnectionCheckInterval no puede validar las conexiones de datos de los servicios inactivos.
Tiempos de espera
Una vez un cliente obtiene una referencia a un servicio, utiliza el servicio durante un período de tiempo antes de liberarlo. La cantidad de tiempo transcurrido desde que un cliente obtiene la referencia de un servicio y hasta que éste es liberado es el tiempo de uso. Para asegurarse de que los clientes no mantienen las referencias a los servicios durante demasiado tiempo (por ejemplo, en caso de que no liberen los servicios correctamente), cada servicio tiene un tiempo máximo que el cliente puede utilizar. Si un cliente retiene un servicio durante un tiempo de uso mayor que el permitido, el servicio será liberado automáticamente y el cliente perderá su referencia al servicio.
El tiempo de uso máximo también evita que los servicios se utilicen para procesar volúmenes de trabajo más elevados que los previstos por el administrador. Por ejemplo, un servicio utilizado por una aplicación que realice comprobaciones de geodatabases puede tener un tiempo de uso máximo de 10 minutos. En cambio, un servicio utilizado por aplicaciones que solo trazan mapas puede tener un tiempo de uso máximo de 1 minuto.
Cuando se alcanza el número máximo de instancias de un servicio agrupado o no agrupado, el cliente que solicite un servicio será enviado a la cola hasta que otro cliente libere uno de sus servicios. La cantidad de tiempo transcurrido entre la solicitud de un servicio por parte de un cliente y la obtención del mismo se llama tiempo de espera. Cada servicio tiene un tiempo máximo durante el que un cliente esperará para obtener un servicio. Si se supera el tiempo de espera máximo de un cliente para un servicio, la solicitud se interrumpirá.
El tercer tiempo de espera indica el tiempo máximo que una instancia inactiva se puede mantener en ejecución. Cuando los servicios dejan de utilizarse, se mantienen en ejecución en el servidor hasta que otro cliente necesita la instancia. Una instancia en ejecución que aún no se encuentra en uso consume memoria en el servidor. Puede minimizar el número de servicios en ejecución y conservar así la memoria acortando el tiempo de espera inactivo, el predeterminado es de 1.800 segundos (30 minutos). El tiempo de espera inactivo de corta duración tiene el inconveniente de que cuando todos los servicios en ejecución se interrumpen, los siguientes clientes tendrán que esperar a que se creen nuevas instancias.
Cuando se crean los servicios en el servidor SIG, ya sea como resultado del inicio del servidor o en respuesta a una solicitud de servidor por parte de un cliente, el tiempo necesario para inicializar el servicio se denomina hora de creación. El servidor SIG incluye un tiempo de espera de inicio que indica la cantidad de tiempo que tarda en iniciarse antes de que el servidor SIG asuma que no se puede iniciar el servicio y cancele su creación. Esta propiedad sólo se puede configurar a través de la edición manual de archivos de configuración de servicios.
El servidor SIG incluye las estadísticas tanto en memoria como en los archivos de registro acerca del tiempo de espera, tiempo de uso y otros eventos que se producen dentro del servidor. El administrador del servidor puede utilizar estas estadísticas para determinar si, por ejemplo, el tiempo de espera de un servicio es muy elevado, lo que podría indicar que es necesario aumentar el número máximo de instancias para dicho servicio.
Limitar la carga en el servidor con la propiedad Capacidad
La capacidad limita el número instancias de servicio que se pueden ejecutar en un equipo de contenedor de objetos de servidor (SOC). Por defecto, la capacidad es ilimitada. Sin embargo, si tiene un equipo con memoria limitada, puede establecer un límite de capacidad para asegurarse de que la huella de memoria de las instancias en ejecución no sobrecarga el equipo.
Cuando el número de instancias de servicio en ejecución en un SOC alcanza la capacidad, el servidor no creará ninguna instancia nueva en ese equipo. Si todos los equipos de SOC han alcanzado la capacidad, entonces se produce el acortamiento de grupo.
Al seleccionar los valores de capacidad, tenga cuidado en no confundir las instancias en ejecución con las instancias "en uso". Las instancias en ejecución consumen memoria pero no potencia de la CPU. Las instancias en uso consumen memoria y CPU. Un servidor que únicamente admita cuatro instancias en uso al mismo tiempo podría admitir más de cuatro instancias en ejecución si tuviera suficiente memoria RAM. Es recomendable que estas instancias estén en ejecución de forma que estén disponibles de inmediato en cualquier momento.
Si el equipo dispone de una gran cantidad de memoria, debería dejar la capacidad fijada en Sin límite.
Explorar:El servidor siempre ejecuta un proceso ArcSOC.exe de fondo adicional que administra el uso de los directorios del servidor. Este proceso carece de importancia respecto a la capacidad.
Cómo se ajusta el servidor a las demandas: acortamiento de grupo
¿Qué sucede cuando un servidor SIG alcanza la capacidad en todos sus equipos de contenedor? ArcGIS Server utiliza el concepto de acortamiento de grupo, que elimina las instancias de servicio de las configuraciones menos populares y las sustituye por instancias de configuraciones más populares.
El acortamiento de grupo tiene lugar cuando el número de instancias de servicio en ejecución ha alcanzado la capacidad en cada equipo SOC. Cuando esto ocurre y el SOM recibe una solicitud de un servicio, el servidor crea la instancia solicitada y destruye una instancia de la configuración de servicio utilizada con menos frecuencia. A continuación, se explica con más detalle los recursos y limitaciones de la agrupación de grupo:
- La agrupación de grupo no destruirá una instancia de un servicio que se encuentre en uso en una aplicación. Si se alcanza la capacidad de todos los SOC y todas las instancias de objeto de servidor en ejecución están en uso, las nuevas solicitudes de instancias deberán esperar en la cola.
- El acortamiento de grupo respeta el número mínimo de instancias que establece para la configuración del servicio y nunca causará que la configuración se sitúe por debajo de su número mínimo de instancias en ejecución.
- El acortamiento de grupo funciona del mismo modo tanto para servicios agrupados como no agrupados.
- El acortamiento de grupo tiene lugar después de establecer los valores de capacidad para cada equipo SOC en el servidor SIG.
- El acortamiento de grupo resulta ser menos eficaz con configuraciones de servicio de aislamiento bajo. Los servicios de aislamiento bajo pueden compartir hasta cuatro instancias dentro de un proceso SOC. Dado que el acortamiento de grupo crea y destruye procesos, afecta a las cuatro instancias en el proceso de aislamiento bajo. Si una de esas instancias se encuentra en uso, no puede tener lugar el acortamiento de grupo.
- El acortamiento de grupo es una forma útil de utilizar recursos de memoria limitados cuando el servidor se encuentra sometido a una carga fuerte; sin embargo, si el acortamiento de grupo se produce con regularidad, el sistema se podría beneficiar si hubiera hardware adicional disponible. Las prácticas de codificación y ajuste de las propiedades del servicio también pueden reducir las cargas en el servidor.
Limitar lo que pueden hacer los usuarios con un servicio
Para facilitar el control del uso de sus servicios Web, cada tipo de servicio tiene un conjunto de operaciones permitidas. Cada operación está formada por un conjunto de métodos que se puede habilitar o deshabilitar como grupo. Los clientes del servicio Web solo pueden realizar llamadas a los métodos de las operaciones para las que dispongan de permiso.
Supongamos que permite el consumo de un servicio Web de representación cartográfica para trazar el mapa pero no para consultar las fuentes de datos de las capas del mapa. En este caso, tendrá que deshabilitar la operación Consulta y asegurarse de que se permite utilizar la operación Mapa.
Si crea un servicio utilizando el asistente Agregar nuevo servicio (en oposición al asistente Publicar recurso SIG), puede seleccionar las operaciones permitidas cuando crea el servicio. Independientemente de cómo haya creado un servicio en un principio, puede cambiar las operaciones permitidas en un servicio existente al editar las propiedades del servicio. Las operaciones disponibles se enumeran en la ficha Recursos del cuadro de diálogo Propiedades del servicio.
En las siguientes tablas se enumeran los métodos incluidos en cada operación:
Operaciones del servicio de mapas
|
Mapa |
Consulta |
Datos |
|---|---|---|
|
GetDocumentInfo |
Identificar |
Buscar |
|
GetLegendInfo |
QueryFeatureCount |
QueryFeatureData |
|
GetMapCount |
QueryFeatureIDs |
|
|
GetMapName |
QueryHyperlinks |
|
|
GetDefaultMapName |
GetSQLSyntaxInfo |
|
|
GetServerInfo |
||
|
GetSupportedImageReturnType |
||
|
ExportMapImage |
||
|
IsFixedScaleMap |
||
|
ToMapPoints |
||
|
FromMapPoints |
||
|
HasSingleFusedMapCache |
||
|
GetTileCacheInfo |
||
|
GetMapTile |
||
|
HasLayerCache |
||
|
GetLayerTile |
||
|
GetVirtualCacheDirectory |
||
|
GetCacheName |
||
|
ComputeScale |
||
|
ComputeDistance |
Las operaciones por defecto permitidas en los servicios de mapas son Mapa, Consulta y Datos.
Operaciones del servicio de geocódigos
|
Geocódigo |
Invertir geocódigo |
|---|---|
|
GeocodeAddress |
ReverseGeocode |
|
GeocodeAddresses |
|
|
StandardizeAddress |
|
|
FindAddressCandidates |
|
|
GetAddressFields |
|
|
GetCandidateFields |
|
|
GetIntersectionCandidateFields |
|
|
GetStandardizedFields |
|
|
GetStandardizedIntersectionFields |
|
|
GetResultFields |
|
|
GetDefaultInputFieldMapping |
|
|
GetLocatorProperties |
Las operaciones por defecto permitidas para servicios de geocódigos son Geocódigo y Geocódigo inverso.
Operaciones del servicio de geodatos
|
Consulta |
Extracción |
Replicación |
|---|---|---|
|
Get_Versions |
ExpandReplicaDatasets |
CreateReplica |
|
Get_DefaultWorkingVersion |
ExtractData |
ExportAcknowledgement |
|
Get_DataElements |
ExportReplicaDataChanges |
|
|
Get_MaxRecordCount |
ImportAcknowledgement |
|
|
TableSearch |
ImportReplicaDataChanges |
|
|
GetNextResultPortion |
ReExportReplicaDataChanges |
|
|
Get_Replicas |
UnregisterReplica |
|
|
Get_WrappedWorkspaceType |
ImportData |
Las operaciones por defecto permitidas para servicios de geodatos son Consulta y Extracción, que habilitan todos los métodos compatibles con consultas y extracción de datos. La elección de Replicación habilita todos los métodos compatibles con sincronización, cambios de datos, reconocimiento de mensajes y esquema.
Operaciones del servicio de globo
|
Globo |
Animación |
Consulta |
|---|---|---|
|
Get_Version |
Get_Animation |
Identificar |
|
Get_LayerCount |
Buscar |
|
|
Get_LayerInfos |
||
|
Get_LegendInfos |
||
|
Get_Config |
||
|
Get_MQT |
||
|
Get_Configuration |
||
|
Get_Tile |
||
|
Get_Symbols |
||
|
Get_Textures |
||
|
Get_VirtualCacheDirectory |
Las operaciones por defecto permitidas para los servicios de globo son Globo, Animación y Consulta. Al contrario de lo que ocurre con los servicios de mapas, la operación de Consulta cubre incluye Identificar y Encontrar.
Operaciones del servicio de imágenes
Imagen | Catálogo | Descargar | Metadatos | Píxeles |
|---|---|---|---|---|
ExportImage | Campos | Descargar | Metadatos | GetNativePixelBlock |
ExportMapImage | GetCatalogItemCount | GetFile | GetRasterMetadata | GetPixelBlock |
GenerateServiceInfo | GetCatalogItemIDs | |||
GetImage | GetCatalogItems | |||
Identificar | GetNativeRasterInfo | |||
ServiceInfo | GetRasterInfo | |||
Versión | GetThumbnail |
Si publica el servicio de imágenes desde un dataset de mosaico, todas los recursos están habilitados por defecto. Si lo publica desde otra fuente, como por ejemplo un dataset ráster, una definición de servicio de imágenes compiladas o un archivo de capa, únicamente se aplican y se habilitan los recursos de Imagen y Metadatos.