Estrategias de Rendimiento de ArcGIS Server

Aaron Lopez

Rendimiento: Desafíos y Estrategias

ArcGIS Enterprise proporciona una plataforma robusta y escalable para ofrecer recursos GIS a los usuarios a través de servicios y aplicaciones web. Sin embargo, a veces las implementaciones pueden experimentar un rendimiento lento desde los puntos finales de recursos publicados.

 

Dado que ArcGIS es muy versátil, puede haber diferentes formas, configuraciones y opciones al poner estos recursos disponibles para su consumo.

Obtener un buen rendimiento no siempre es tan fácil y directo como simplemente activar una configuración "fast = true".

Lo que podría ser una característica útil para algunos administradores podría ser una configuración que, aunque útil, puede interferir con el rendimiento para otros. 

 

En el mundo real, el rendimiento suele ser función de varios elementos y configuraciones. Tener estrategias para entender y superar los más comunes puede ayudar a poner la implementación en camino hacia lograr un rendimiento más rápido.

¿Qué es el Rendimiento?

El rendimiento es una descripción de qué tan rápido (o lento) opera un servidor o servicio para una función particular de interés. Cuánto tiempo tarda un servicio de ArcGIS Server en completar una operación como query, applyEdit o export y luego enviar la respuesta de vuelta al cliente que la solicitó sería un ejemplo de rendimiento.

 

Esta duración se mide en segundos o milisegundos y comúnmente se denomina tiempo de respuesta.

Aunque se llama "tiempo de respuesta", hay varios pasos importantes que conforman el tiempo total que un cliente como un navegador web o ArcGIS Pro pasa esperando un recurso solicitado del servidor:

1. Búsqueda DNS del nombre del servidor
2. Handshake SSL entre cliente y servidor
3. Conexión TCP/IP entre cliente y servidor
4. Envío de la solicitud al servidor
   1. Procesamiento de la solicitud por el servidor
5. Recepción de la respuesta del servidor
   1. Para respuestas grandes, se puede usar Tiempo hasta el primer byte (TTFB) para medir el tiempo de respuesta

Típicamente, la mayor parte del tiempo se gasta en 4.1. Aquí es donde el servidor está trabajando en la respuesta.

Este Artículo de la Comunidad explorará áreas que pueden impactar esta parte del tiempo de respuesta.

¿Por qué es Importante el Rendimiento?

Sencillamente: cuanto más rápido sea el rendimiento, menor será el tiempo de respuesta. 

Cuanto menor sea el tiempo de respuesta, más solicitudes puede soportar el servidor al mismo tiempo.

Esta mayor concurrencia de solicitudes se traduce en mayor escalabilidad, lo que finalmente significa soporte para más usuarios.

 

El rendimiento se mide como una unidad de tiempo necesaria para completar una sola operación a la vez (por ejemplo, 0.238 segundos para ejecutar una solicitud de consulta de entidad). 

La escalabilidad, por otro lado, se mide frecuentemente como transacciones u operaciones sobre tiempo (por ejemplo, solicitudes/seg o operaciones/hora).

 

Cuando se habla de obtener mejor, más rápido o "más" rendimiento, implica lograr tiempos de respuesta más bajos. Por otro lado, mejor escalabilidad implica alcanzar una tasa más alta de rendimiento (por ejemplo, más operaciones/hora).

 

Nota: Por supuesto, para obtener mejor rendimiento o rendimiento máximo, las operaciones de interés deben ejecutarse adecuadamente y responder con el contenido esperado (por ejemplo, imagen del mapa, json o datos pbf). Los mensajes de error, por ejemplo, pueden ser una respuesta rápida y simple cuya entrega puede alcanzar una alta tasa de rendimiento. Como evaluadores y analistas, este tipo de rendimiento no es lo que buscamos... nos interesa el rendimiento de solicitudes exitosas.<\/SPAN>

¿Qué es un Rendimiento Aceptable?

Depende. 

Los criterios o requisitos para clasificar un elemento como con rendimiento rápido (o lento) pueden variar mucho según la organización, los servicios publicados y las operaciones esperadas que los usuarios llamarán.

No es raro tener diferentes objetivos de tiempo de respuesta para funciones de ArcGIS Server o flujos de trabajo de aplicaciones usuario (varias solicitudes agrupadas para representar una operación).

Cualquier número de segundos está bien como requisito pero tenga en cuenta que puede requerir más hardware así como ajustes y estrategias más extensas (este Artículo) para lograr objetivos agresivos.

¿Cómo se Mide el Rendimiento?

El tiempo de respuesta es la métrica clave para determinar si el rendimiento está cumpliendo o manteniéndose dentro o por debajo del requisito objetivo.

Estrategias comunes para medir son:

• Interacción con usuario único
  • A través del navegador web o ArcGIS Pro
    • Este es el lugar más fácil para comenzar
      • Si aún no hay comprensión sobre el rendimiento, comience aquí
• Análisis estadístico de grandes volúmenes de tiempos de respuesta
  • A través de herramientas de análisis de registros, la página Estadísticas del Administrador ArcGIS Server u otras utilidades de observabilidad
    • Estos enfoques tienen la ventaja de analizar solicitudes reales que los usuarios ya han ejecutado contra la implementación
  • Esto se discute con más profundidad más adelante en el Artículo
• Pruebas de Carga
  • Pueden proporcionar comprensión sobre rendimiento y escalabilidad 
  • Más laborioso configurar
  • Existen recursos en línea para comenzar
    • Ingeniería del Rendimiento: Pruebas de Carga en ArcGIS Enterprise 

Al analizar registros o ejecutar pruebas, una estrategia común es aprovechar las estadísticas para desglosar grandes cantidades de tiempos de respuesta. El Promedio y percentil 90 (o 95), el Mínimo y Máximo ayudan a proporcionar comprensión del rendimiento que el usuario pudo haber experimentado.

Captura de Tiempos de Respuesta -- Navegador Web

Cómo se capturan los tiempos de respuesta mediante interacción con usuario único es un tema divertido para discutir.

El enfoque más fácil para capturar tiempos de respuesta de solicitudes REST desde una aplicación web es con la funcionalidad "herramientas para desarrolladores" del navegador. Todos los navegadores principales ofrecen alguna vista de las solicitudes, respuestas y tiempos enviados y recibidos. Esta duración puede dar una idea qué tan rápido se realizó una solicitud u operación (potencialmente múltiples solicitudes). Luego se pueden tomar decisiones si esto es aceptable o necesita mejorar.

 

Captura de Tiempos de Respuesta -- ArcGIS Pro

Aunque ArcGIS Pro también se comunica con ArcGIS Enterprise vía REST, no tiene un equivalente incorporado a las herramientas para desarrolladores. Para capturar tiempos de respuesta necesitará un depurador HTTP separado. Hay muchos disponibles; una opción popular es Fiddler.

Con Fiddler instalado en la misma máquina que ArcGIS Pro, puede configurarse para interceptar el tráfico. Los parámetros de solicitud, contenido y tiempos pueden capturarse y examinarse similarmente.

1Son necesarios objetivos para mejorar el rendimiento? 3?

Totalmente no. Los Administradores GIS siempre pueden analizar, ajustar y aplicar mejores prácticas al sistema incluso si no hay requisitos oficiales sobre rendimiento.
Sin embargo, se recomienda encarecidamente entender qué rendimiento está entregando inicialmente su sistema (por ejemplo, estos suelen denominarse números base del tiempo de respuesta) antes hacer ajustes. De esta manera puede determinar si los cambios aplicados están teniendo un efecto positivo.

Desafíos Comunes del Rendimiento y Estrategias Potenciales

Tipos y Instancias del Pool del Servicio

< DIV >< P >< SPAN > Una área frecuente donde los administradores ArcGIS encuentran desafíos con el rendimiento es establecer el número apropiado instancias para servicios dedicados . Pero primero revisemos los diferentes tipos.  Hay 3 tipos servicio , cada uno con sus propias fortalezas . </ P ></ DIV >< UL >< LI >< STRONG > Dedicado </ STRONG ></ LI >< LI >< STRONG > Hospedado </ STRONG ></ LI >< LI >< STRONG > Compartido </ STRONG ></ LI ></ UL >< DIV >< P > Como Administrador GIS , es importante poder identificar el tipo instancia para un servicio.<\/P>Esto se puede ver fácilmente dentro de ArcGIS Server Manager, bajo Administrar Servicios:<\/DIV>

 <\/DIV>

<\/span><\/P><\/DIV>Seleccionando el Tipo Apropiado<\/SPAN><\/H3>Elegir un tipo de servicio dedicado es ideal cuando se desea lograr el máximo control de rendimiento y escalabilidad<\/U>. Con este tipo, el administrador puede:<\/P><\/DIV>Establecer el número máximo de instancias al número de núcleos de CPU para aprovechar al máximo la capacidad de procesamiento disponible en la máquina ArcGIS Server (a través del máximo)<\/SPAN><\/LI>Conservar memoria cuando está inactivo (a través del mínimo)<\/SPAN><\/LI>Ajustar para un rendimiento predecible estableciendo el mínimo y máximo al mismo valor<\/SPAN><\/LI><\/UL>Los servicios dedicados son ideales para servicios con muchas solicitudes o servicios donde el rendimiento es primordial.<\/P>Los servicios alojados no utilizan instancias ArcSOC y escalan automáticamente según sea necesario. Sin embargo, las capacidades de ArcGIS disponibles para ellos (Alojados) son limitadas ya que se usan principalmente con consultas de entidades.<\/P>Los servicios compartidos son excelentes para acceder a elementos que se solicitan con menos frecuencia. Normalmente tienen más capacidades de ArcGIS disponibles pero no toda la funcionalidad de ArcGIS está disponible (por ejemplo, versionado ramificado). Un grupo de instancias compartidas es el tipo predeterminado al publicar un servicio con ArcGIS Pro<\/U>.<\/P>Nota: Es importante reiterar que si el tipo de servicio seleccionado está configurado como dedicado, se debe evaluar el número (mínimo y máximo) de instancias para asegurar que sean óptimos. El valor predeterminado al publicar en ArcGIS Pro es usar solo un máximo de 2 (instancias). Esto podría ser demasiado bajo e inadecuado para servicios donde el rendimiento/escalabilidad son importantes.<\/STRONG><\/FONT> <\/SPAN><\/P><\/DIV>Enfocar el Mapa<\/H2>Optimizar el mapa no es una estrategia nueva pero sí relativamente fácil de seguir para obtener mejor rendimiento en su implementación.
Cuando el mapa está enfocado en su propósito principal y presentación, el sistema no tiene que hacer trabajo innecesario. Recuerde, la web es una plataforma multiusuario. Hacer que la visualización de los datos dinámicos sea lo más eficiente posible es clave para un buen rendimiento (y escalabilidad). Con potencialmente muchas solicitudes ocurriendo al mismo tiempo, el contenido compartido necesita ser lo más eficiente posible.<\/P><\/span>Estrategias del Mapa<\/SPAN><\/H3>Elegir una Extensión Predeterminada Óptima<\/SPAN>Si el mapa proporciona datos sobre Los Ángeles, la extensión predeterminada no<\/EM> debería mostrar todo California<\/LI>Si se requieren muchas escalas diferentes del mapa, use dependencias de escala y generalización para limitar el detalle a cuando más lo necesite (por ejemplo, las escalas más grandes)<\/LI><\/UL><\/LI>Eliminar capas innecesariasConsidere eliminar capas de datos agradables de tenerAl menos, desmárcalas y permita que el usuario opte por activarlas<\/LI><\/UL><\/LI><\/UL><\/LI>Limitar intencionalmente lo que los usuarios pueden hacer con un servicio<\/LI>Evitar proyectar sobre la marchaUsar el mismo sistema de coordenadas para el marco de datos y los datos<\/LI><\/UL><\/LI>Consultas de definiciónAsegurar que los índices estén en su lugar si se aplica lógica comparativa a columnas de atributos <\/LI><\/UL><\/LI><\/UL>Nota: "Enfocar el mapa" aplica a mapas, aplicaciones y servicios<\/FONT><\/STRONG><\/DIV>Lanzamientos de Software<\/H2>Una versión particular de ArcGIS Enterprise (y sus soluciones relacionadas) puede tener un puñado de parches después de su lanzamiento base inicial. Estos parches pueden ofrecer mejoras en rendimiento así como correcciones de funcionalidad y seguridad. <\/P>Se recomienda encarecidamente revisar periódicamente el sitio Esri Patches and Updates<\/A> o ejecutar la herramienta "Check for ArcGIS Enterprise Updates". Luego, aplicar las actualizaciones en el momento apropiado.<\/P>

Contención y Expansión de Recursos<\/H2>Hay ocasiones en las que se aplican las mejores prácticas y estrategias para rendimiento pero aún se requieren tiempos de respuesta más bajos y mayor escalabilidad. Quizás el hardware actual que ejecuta ArcGIS Server simplemente está agotado donde la potencia de procesamiento o memoria se han convertido en el cuello de botella para mejorar la experiencia del usuario.<\/P>Para tales situaciones, debe considerar la expansión y/o actualización del hardware.<\/DIV>

Escalabilidad<\/SPAN>

Para los niveles ArcGIS Server y ArcGIS Web Adaptor del despliegue, generalmente< \/STRONG >< \/EM > tiene las siguientes opciones para mejorar escalabilidad< \/EM > usando hardware: < \/SPAN >< \/DIV >Escalar hacia arriba< \/STRONG >Agregar más recursos a la máquina existente (por ejemplo, núcleos adicionales de procesamiento)< \/SPAN >La memoria adicional también puede ayudar con la escalabilidad permitiendo que la implementación tenga más instancias ArcSOC ejecutándose simultáneamente< \/SPAN > < \/SPAN >< \/LI >< \/UL >< \/LI >Ideal para implementaciones tales como: nube, virtualización, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >Escalar hacia afuera< \/STRONG >Agregar más máquinas con igual capacidad de recursos< \/SPAN >< \/LI >Ideal para implementaciones tales como: local, nube, virtualización, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >Rendimiento< \/SPAN >Para mejorar rendimiento< \/EM > con hardware, típicamente hay solo una opción:< \/SPAN >Obtener núcleos de procesamiento más rápidos< \/STRONG > Ideal para implementaciones tales como: nube, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >La configuración del paginador del sistema también puede impactar la escalabilidad incluso cuando se han agregado suficientes recursos de memoria a un sistema. Aunque esta es una configuración del software del sistema operativo y no hardware, puede jugar un papel crucial en la ejecución de muchas instancias concurrentes ArcSOC. Asegúrese de configurarlo adecuadamente para manejar una carga con muchas instancias o instancias con una gran huella de memoria.< \/FONT >Puede haber situaciones donde el rendimiento está limitado y parece estar atado a CPU (por ejemplo, un cuello de botella debido a potencia limitada de procesamiento). Una inspección adicional puede revelar que el "culpable" son una o más consultas lentas que fueron subóptimas desde el principio o una operación costosa llamada con demasiada frecuencia (a través de tareas administrativas periódicas). En tal caso, puede ser más efectivo abordar las consultas "malas" para mejorar rendimiento y escalabilidad.< \/FONT >Nota: Estas estrategias de expansión son para superar limitaciones generales< \/EM >de procesamiento y memoria. Pero los recursos de disco y red (ancho de banda, latencia) también pueden ser cuellos de botella. Para algunos entornos, estos pueden ser más complicados de ampliar requiriendo pasos adicionales para actualizar.< \/STRONG >Un Enfoque General para Escalar<\ /FONT > Para ArcGIS Server puede ser más fácil escalar hacia arriba primero, luego hacia afuera. La razón es debido a la configuración del Sitio y directorios que necesitarían ser migrados a almacenamiento compartido si la arquitectura cambia desde una máquina única a un despliegue multi-máquina.<\ /DIV >  <\ /DIV >  <\ /DIV > ¿Cuánto debería escalar... dos servidores, cinco servidores? Sin detalles sobre tiempos promedio de respuesta y número anticipado de usuarios a soportar, es difícil proporcionar una respuesta concisa.<\ /P > Sin embargo, un enfoque simplista,<\ STRONG > general <\ /EM > sería simplemente intentar doblar la cantidad actual (memoria y/o núcleos físicos) y observar el impacto.<\ /P > En muchos casos, esto probablemente funciona bien hasta 16 CPUs. En ese punto, agregar otra máquina puede ser más ventajoso.<\ /P > <\ /DIV >  <\ /DIV > Nota: Su licencia actual del producto puede afectar cuántos núcleos físicos puede usar con ArcGIS Server. Consulte con su Gerente de Cuenta Esri para más detalles.<\ /STRONG >

 <\ /DIV >

Nota: Para soporte con planificación de capacidad o diseño arquitectónico (lo cual puede ayudar a proporcionar una comprensión detallada y estimación sobre los recursos hardware requeridos para un conjunto dado de flujos de trabajo), contacte a Todd Jarrard (tjarrard@esri.com) en Esri Professional Services.<\ /STRONG >

Observabilidad

"Cuantificar ArcGIS" es una gran estrategia... un favorito personal. Define qué recursos se estaban solicitando y qué tan rápidas fueron las respuestas para cumplir con estas solicitudes. Es importante para obtener una comprensión del rendimiento general del sistema. Si también se puede capturar la utilización de recursos del sistema, el análisis puede elevarse aún más.

Hay muchas utilidades disponibles para examinar periódicamente su sistema. Algunas herramientas pueden leer los registros de acceso y centrarse principalmente en el rendimiento estadístico de las solicitudes realizadas por los usuarios. Otras pueden consultar la página de estadísticas del Servidor y capturar la utilización de CPU (de ArcGIS Server o la base de datos) durante ese período de tiempo. ¿Cuál enfoque es el mejor? Si actualmente no se está realizando observabilidad, entonces lo más probable es que cualquiera de ellas sea una buena adición. Todas ayudan a proporcionar algún tipo de visión sobre el rendimiento y la salud del despliegue. 

Una vez que se ha realizado el análisis para un despliegue, normalmente se pueden generar informes que destacan qué servicios de mapas podrían ser de interés debido a:

• Los tiempos de respuesta observados son más lentos de lo esperado
• El número de solicitudes emitidas para el recurso
• Tanto el tiempo de respuesta como el número de solicitudes

Para un Sitio ArcGIS con muchos servicios, saber cuáles son estadísticamente lentos o están consumiendo la mayoría de los recursos ayuda a enfocar los esfuerzos de optimización. Con tales informes, el administrador GIS ha convertido datos en información valiosa y ahora está mejor informado para tomar decisiones que mejoren la experiencia del usuario. Dicho esto, examinar registros y estadísticas es solo una (importante) parte del análisis.

Un Desafío con las Herramientas Comunes de Observabilidad

Muchas herramientas para la observabilidad y monitoreo del sistema centran el análisis en las solicitudes y respuestas para servicios. Este es un buen enfoque y definitivamente ayuda a los administradores a cuantificar ArcGIS, pero puede tener una limitación. La limitación puede aparecer con la suposición de que un servicio de mapas lento puede "arreglarse" simplemente agregando núcleos de procesamiento. Más núcleos podrían mejorar algunos aspectos de la situación, pero se recomienda que el servicio sea examinado (o incluso reexaminado) en mayor profundidad antes de obtener más recursos.

Esto vuelve a la sección "Enfocar el Mapa", por ejemplo:

• Asegurarse de que los datos para el servicio no se muestren a escalas demasiado pequeñas
• Evitar consultas subóptimas

El análisis detallado de consultas puede ayudar a mostrar la ocurrencia de estos comportamientos que podrían quedar enmascarados con informes generales del servicio. Sin embargo, mientras que el desglose de parámetros de solicitud del servicio y las consultas subyacentes pueden mejorar el análisis, puede agregar complejidad al informe mismo (por ejemplo, más tiempo para ejecutar, más vistas sobre qué observar, la comprensión de las vistas). Además, no todas las herramientas de observabilidad realizan este tipo de inspección.

Algunos esfuerzos recientes que están ganando tracción intentan abordar este problema. Se basan en un enfoque ascendente del análisis donde el punto de partida son las consultas subyacentes a la base de datos mismas mediante un mecanismo conocido como "query datastore". El análisis query datastore es poderoso y no impacta el rendimiento de la base de datos como puede hacerlo un trace, pero requiere cierto conocimiento sobre las consultas mismas y su propósito. Espere este tipo de capacidad analítica en el futuro para ayudar a aprovechar al máximo sus herramientas de observabilidad.

Conclusión

No hay un solo elemento que se pueda ajustar fácilmente para aumentar el rendimiento y la escalabilidad de un Sitio ArcGIS Enterprise. Sin embargo, este Artículo enumera algunas estrategias comunes que pueden aplicarse juntas para mejorarlo. También es importante entender que estos son elementos que deben revisarse periódicamente y actuarse en consecuencia. Los hábitos del usuario cambian con el tiempo al igual que la popularidad de una aplicación web o servicio. Los recursos asignados a un servicio particular pueden reevaluarse o reducirse para dar espacio al próximo elemento destacado en su Sitio.

El análisis del rendimiento en ArcGIS puede ser divertido pero también es un esfuerzo continuo para mantener la mejor experiencia del usuario.

 

 

Atribución

 

Recurso: Archivo:Grayson_running_the_4x100.jpg

Descripción: Inglés: Grayson corriendo la primera etapa del 4x100 en la invitación Tigered 2010

Autor: Graysonbay

Creado: 02:02, 29 noviembre 2010

Licencia: Este archivo está licenciado bajo Creative Commons Attribution 3.0 Unported license

 

Recurso: Archivo:Kurvimeter_1_fcm.jpg

Autor: Frank C. Müller, Baden-Baden

Licencia: Este archivo está licenciado bajo Creative Commons Attribution-Share Alike 4.0 International license.

 

Recurso: Archivo:My_Opera_Server.jpg

Descripción: Un servidor usado para My Home

Autor: William Viker, william.viker@gmail.com (c) 2006

Licencia: El titular del copyright de este archivo permite que cualquiera lo use para cualquier propósito, siempre que el titular del copyright sea debidamente acreditado. Se permite redistribución, obras derivadas, uso comercial y todo otro uso.

 

Recurso: Archivo:Samsung-1GB-DDR2-Laptop-RAM.jpg

Descripción: Un módulo de memoria RAM DDR2 667 MHz (PC2-5300) para laptop de 1 gigabyte, fabricado por Samsung y extraído de una laptop MacBook 2007.

Autor: Evan-Amos

Creado: 1 agosto 2018

Licencia: Dominio Público

 

AndreaB_

@AaronLopez Wonderful, thank you so much! Exactly the clarification and info that I needed and couldn't find all in one spot, (or anywhere, in some cases)! I'll be thinking about all of this as I try to get the response times lower than 0.5 seconds for these map services.