Resultados de pruebas sobre el impacto en los recursos de la base de datos
En nuestro primer conjunto de pruebas, analizamos el impacto de los recursos de la base de datos en la capacidad del sistema para gestionar la carga, incluso con abundantes recursos del servidor GIS. Esto pretende mostrar hasta qué punto la base de datos influye en el rendimiento del sistema en su conjunto. En otras palabras, si los usuarios experimentan tiempos de espera prolongados, es posible que el problema no se encuentre únicamente en la capa de ArcGIS Server.
Nota:
Estas pruebas se realizaron con una configuración optimizada de la base de datos para destacar que una base de datos correctamente dimensionada desempeña un papel fundamental en el rendimiento general del sistema ArcGIS. Sin embargo, en sus propios sistemas, debería centrarte en optimizar y ajustar su base de datos antes de escalar su hardware. Mejorar el rendimiento de la base de datos mediante tareas de ajuste suele ser más rentable y puede resolver problemas de bajo rendimiento percibido sin necesidad de realizar inversiones adicionales en infraestructura.
Métodos de prueba y resultados
Realizamos dos pruebas para comparar cómo los recursos de la base de datos afectan al rendimiento del sistema, incluso con suficientes recursos del servidor:
- Primero, utilizando una instancia pequeña de máquina virtual de base de datos con 8 vCPU.
- Después, con una instancia más grande de máquina virtual de base de datos con 16 vCPU.
Mantuvimos constantes todos los demás aspectos del sistema, con una configuración ArcSOC 1:1. En otras palabras, se configuró un ArcSOC por cada vCPU en la instancia de ArcGIS Server, de modo que el número de ArcSOC y de vCPU era el mismo. Capturamos y monitorizamos métricas de rendimiento como el uso y disponibilidad de ArcSOC, tiempos de espera del servicio, utilización de recursos del sistema y error tasas para evaluar cada configuración. Las pruebas se realizaron con una carga ocho veces superior (8x) a la carga de diseño del estudio original del sistema, y los recursos del servidor de ArcGIS Enterprise se redujeron a la mitad (en comparación con nuestros estudios de prueba anteriores) para garantizar que hubiera suficiente carga como para afectar al sistema.
Dado que ArcGIS es un sistema de varios niveles, las pruebas se realizaron en los niveles de cliente, servicio y almacenamiento de datos, así como en la propia infraestructura subyacente. En este estudio de prueba, se utilizó JMeter para simular los flujos de trabajo de los usuarios y medir el rendimiento del sistema bajo otro tipo de cargas.
Prueba de carga 1: instancia de base de datos pequeña – 8 vCPU
Esta ejecución se realizó con 8 vCPU disponibles en la instancia de PostgreSQL para observar el impacto del sistema en un servidor de base de datos reducido. ArcGIS GIS Server (UN Server) también se aprovisionó con 8 vCPU. A continuación se muestran seis gráficos de recursos de instancias que reflejan la utilización de recursos en todo el sistema y un gráfico adicional que muestra las solicitudes concurrentes. En cada uno de los gráficos de recursos, las líneas naranjas representan el porcentaje de uso de CPU, las líneas doradas representan el porcentaje de uso de disco y la línea morada representa el porcentaje de uso de memoria.
En el diagrama de abajo, puede ver que la base de datos de PostgreSQl tiene la CPU funcionando al 100% y la CPU del servidor anfitrión tiene picos frecuentes hasta el 100%. Esto se debe al alto número de solicitudes de visualización asociadas con los flujos de trabajo con la carga de diseño 8x.
El gráfico inferior muestra las solicitudes concurrentes, medidas a partir de los registros de JMeter. Observe que la línea roja, que representa las solicitudes de visualización concurrentes, aumenta hasta 538 a medida que se ejecuta la prueba. Esto indica que las solicitudes no se están cerrando. En gráficos posteriores, verá esta línea moverse de forma constante arriba y abajo, indicando que el sistema responde y que las solicitudes se cierran lo suficientemente rápido para manejar la carga.
Esta configuración no soportaba la carga porque el servidor de base de datos estaba infravalorado, como se ve en la cantidad de naranja (utilización de la CPU) en el gráfico de la base de datos PostgreSQL, los picos en la CPU del servidor anfitrión y el número de solicitudes concurrentes.
Para reforzar aún más esta afirmación, el gráfico siguiente representa la utilización de ArcSOC en el servidor anfitrión tal como la captura la utilidad Soccer (ArcSOC Monitoring), que se ejecuta en una máquina remota. La línea roja muestra los ArcSOC ocupados al 100% (8), probablemente atribuidos a la base de datos sobrecargada. Los ArcSOC permanecen ocupados mientras esperan a que la base de datos responda. De hecho, los ArcSOC estaban tan ocupados que Soccer no pudo seguir su estado, como ilustran la línea roja incompleta y las caídas repentinas en el máximo (línea verde).
Prueba de carga 2: instancia de base de datos grande – 16 vCPU
En la segunda prueba, duplicamos la instancia de la base de datos PostgreSQL a 16 vCPU para observar posibles diferencias respecto a la primera prueba. Los servidores ArcGIS GIS Server siguieron aprovisionados con 8 vCPU cada uno. Como en el diagrama anterior, el porcentaje de utilización de la CPU es naranja, el disco es dorado y la memoria es morada. Obsérvese que, salvo algunos picos, todos los servidores funcionan en general por debajo del 60% de uso de CPU, disco y memoria.
El gráfico de solicitudes concurrentes muestra una media de 36 solicitudes de vista simultáneas, con algunos picos. Las solicitudes abiertas no muestran una tendencia ascendente como en el gráfico anterior, lo que indica que este sistema está gestionando la carga.
El gráfico de ArcSOC que aparece a continuación muestra que los ArcSOC en el servidor anfitrión están ocupados, pero la respuesta general del sistema es buena. Aunque el 99% (p99) del uso son 8 socs o menos, la media es 4,81. Más adelante analizaremos la experiencia de usuario para ver si el sistema permite que las personas trabajen de forma eficiente.
Experiencia de usuario
Además de la utilización y el rendimiento general del sistema, los recursos adicionales disponibles en la instancia de la base de datos mejoraron significativamente la capacidad del usuario final para completar su trabajo de forma eficiente. Este estudio de prueba evaluó la eficiencia del usuario final observando los tiempos de ejecución del flujo de trabajo: cuánto tarda un usuario en completar los pasos del flujo de trabajo, así como los tiempos de ejecución del paso del flujo de trabajo, es decir, cuánto tiempo tardó en completar un paso clave dentro de un flujo de trabajo.
Nota:
La experiencia del usuario es la medida definitiva en estos estudios de prueba. Hemos visto durante las pruebas que, incluso cuando el sistema parece funcionar dentro de parámetros normales, aspectos como la latencia de red, la implementación de la GPU, la mala configuración de instancias de mapa, etc., pueden afectar negativamente a los usuarios finales. Céntrese en los usuarios finales para mejorar el retorno de la inversión.
En el gráfico anterior puede verse cómo una mayor saturación de los recursos del sistema en la prueba con la base de datos pequeña da lugar a tiempos de ejecución más largos en los flujos de trabajo, lo que se traduce en una peor experiencia general para el usuario final. El tiempo total de ejecución de todos los flujos de trabajo aumentó de forma significativa con una base de datos insuficientemente dimensionada en comparación con una correctamente dimensionada, incluso cuando ArcGIS Server contaba con recursos adecuados. En particular, el flujo de trabajo Ver activos experimentó una reducción drástica del tiempo de ejecución cuando se utilizó una geodatabase corporativa correctamente dimensionada.
Además del tiempo de ejecución del flujo de trabajo, podemos analizar con mayor profundidad cómo los recursos de la base de datos afectan a la duración de pasos concretos del flujo de trabajo de edición. No obstante, sí muestra la gran diferencia en el tiempo necesario para abrir un proyecto y localizar un activo en el flujo de trabajo Actualizar activo. De manera similar, Trazado eléctrico mostró un aumento significativo en todos los pasos del flujo de trabajo. Este patrón se mantuvo en todos los flujos de trabajo analizados.
