oficina GIS en una caja<\/A>, por ejemplo. Como cualquier oficina, el acto de equilibrar el número de personal vs. la demanda vs. los recursos es un cálculo continuo. Y eso es cierto también en nuestra oficina ArcGIS en una caja. La mayoría de las oficinas GIS están limitadas en capacidad de personal por factores como estaciones de trabajo disponibles, ancho de banda de red o licencias del software esencial. Si nos quedamos sin escritorios y computadoras que los analistas puedan usar, no podemos agregar más analistas a la oficina. Si todos los analistas están trabajando en algunas tareas, no podemos pedir que se inicie una nueva tarea. Incluso si ampliamos el espacio y agregamos infraestructura, no podemos usar esa capacidad aumentada si no compramos más licencias de ArcGIS Pro. Con ArcGIS Server podemos enfrentar los mismos desafíos y límites. Por lo tanto, es vital configurar los servicios web GIS (services) que se ejecutan en ArcGIS Server para usar eficientemente los recursos finitos disponibles, asegurando también el mejor rendimiento y velocidad para el sistema.<\/P> <\/P>
Cada servicio no alojado en ArcGIS Server tiene un conjunto de opciones de configuración que pueden definirse al momento de la publicación en ArcGIS Pro o después de la publicación con la aplicación web administrativa ArcGIS Server Manager. Un servicio puede existir en ArcGIS Server en muchos estados. Primero se publica. Esto significa que se ha creado un archivo de definición del servicio, y existe dentro del directorio Server en una subcarpeta llamada arcgisinput, por defecto esto se encuentra en C:\arcgisserver\directories\arcgissystem\arcgisinput. Segundo, el servicio puede estar funcionando o detenido. Por defecto, los servicios publicados se inician cuando se publican, aunque también pueden detenerse. Cuando un servicio está iniciado y funcionando está "advertised" en otra aplicación web llamada ArcGIS Server Services Directory. Aquí administradores, publicadores y desarrolladores encuentran propiedades útiles y operaciones soportadas que pueden usarse para inspeccionar y usar los servicios.<\/P>
<\/P>
Otro resultado de iniciar un servicio en ArcGIS Server es que los componentes manager de nuestra "oficina" iniciarán el número mínimo de instancias configuradas para el servicio, por defecto esta es una instancia. Técnicamente una instancia de un servicio es una unidad única de procesamiento, típicamente manifestada como un proceso ArcSOC.exe ejecutándose en el sistema operativo del equipo anfitrión. Puedes pensar en una instancia de un servicio como un analista sentado en un escritorio con el proyecto requerido de ArcGIS Pro disponible para responder a solicitudes para capacidades definidas del recurso GIS anunciado. Nota que el número de instancias funcionando no está directamente relacionado con el número de aplicaciones ni personas "usando" el servicio. En este caso la instancia está funcionando y solo esperando una solicitud. Esto se llama estado idle de la instancia.<\/P>
<\/P>
ArcGIS Server Manager y Administrador de tareas de Windows mostrando instancias de un servicio web GIS.<\/span><\/span><\/P> <\/P>El número mínimo de instancias define cuántas instancias del servicio se inician cuando el servicio se inicia. Esto puede establecerse a cualquier número incluyendo cero. Pero no te vuelvas loco con este número, recuerda que el servidor GIS tiene recursos finitos disponibles y probablemente hay otros servicios funcionando que necesitan usar esos recursos para soportar sus instancias también. Pero eso es solo el mínimo. También hay un número máximo de instancias que pueden ser instanciadas. Este máximo puede ser mayor o igual al número mínimo de instancias. Por defecto, este número es dos. Así que, por defecto cuando un servicio se publica en ArcGIS Server, el mayor número de analistas virtuales que pueden existir para responder a solicitudes a ese servicio es dos. ¿Será eso suficiente? Lo más probable es que no. Especialmente si este es un servicio con demanda media a alta. Pero nuevamente, recuerda que aunque puedes establecer este máximo a cualquier número, puedes fácilmente saturar tu sistema permitiendo más instancias creadas que las que el sistema total puede manejar. Además, habrá otros servicios funcionando en ArcGIS Server con sus propias instancias que necesitan consumir esos recursos finitos también.<\/P> <\/P>
ArcGIS Server Manager con configuraciones de instancia.<\/span><\/span><\/P> <\/P>Hasta ArcGIS 10.7, esta era la única forma de controlar el número de analistas (instancias) que existían en nuestra oficina GIS (ArcGIS Server). Todas las instancias existentes en ArcGIS Server se definían para cada servicio por separado y solo podían responder a solicitudes para ese servicio. Podemos pensar en esto como si cada analista en nuestra oficina GIS solo pudiera abrir un proyecto a la vez en ArcGIS Pro y el proyecto solo pudiera tener un mapa, o escena, o modelo u otro recurso GIS único con el cual el analista pueda interactuar para responder solicitudes. Estos son referidos como instancias dedicadas.<\/P> <\/P>Luego, en ArcGIS 10.7, introdujimos un nuevo concepto llamado shared instance pool. Las instancias en este pool pueden responder a solicitudes a cualquier servicio asignado a él, con ciertos límites sobre qué tipos de servicios pueden ser asignados al mismo. Puedes considerar este shared instance pool como algunos analistas en nuestra oficina que tienen una copia del mismo proyecto abierto en ArcGIS Pro que tiene muchos mapas (uno para cada servicio asignado al pool) disponibles dentro del mismo. El beneficio que esto trae es que los servicios con baja demanda ya tienen instancias corriendo para soportarlos rápidamente, pero los recursos computacionales no se desperdician en instancias que no están siendo usadas.<\/P> <\/P>Una última consideración al hablar sobre instancias de un servicio es que no todos los servicios a los cuales nuestros usuarios tienen acceso son gestionados como servicios separados en ArcGIS Server. Por ejemplo, cuando publicas un map service hay un map service disponible en Server Manager para gestionar propiedades como el número min/máximo de instancias. Ese map service también tiene su propia URL o punto final por donde los clientes se comunican. Pero el objeto map service en ArcGIS Server Manager también tiene una propiedad capabilities. A través de esta propiedad pueden habilitarse capacidades adicionales como feature access capability. Habilitar esto hará que ArcGIS Server cree otra URL para un feature service. Pero este feature service y cualquier otro servicio habilitado vía capability no instancia sus propias instancias. Las instancias originales creadas para el map service asociado también soportan al feature service.<\/P> <\/P>
ArcGIS Server Manager mostrando la URL de un map service.<\/span><\/span><\/P> <\/P>
ArcGIS Server Manager mostrando la URL de un feature service.<\/span><\/span><\/P> <\/P>A través de este artículo hemos visto que hay muchas formas mediante las cuales podemos controlar y gestionar servicios web GIS para afectar el rendimiento proporcionado por ArcGIS Server. Pero ArcGIS Server es solo una parte del proceso de crear, gestionar y compartir recursos GIS. En la mayoría de los casos las decisiones que tomamos al almacenar los datos GIS o al crear los recursos tendrán un mayor impacto que estas opciones. En el currículo formativo dirigido por instructores de Esri discutimos e implementamos muchas técnicas específicas para optimización del contenido en nuestro curso
