Métodos de prueba y resultados

Se realizaron pruebas para validar que el diseño funcionaría como se esperaba y admitiría los flujos de trabajo, los usuarios y la carga prevista. Las pruebas del sistema ofrecen la oportunidad de descubrir y corregir problemas durante la implementación del sistema en entornos inferiores, idealmente antes de que aparezcan en la producción. En este estudio de prueba, el enfoque de la estrategia de prueba se centró en validar que el sistema pudiera dar soporte a los flujos de trabajo y comprender cómo la carga afectaría al sistema y a sus componentes, así como a la experiencia del usuario final.

Se monitorizaron todos los componentes a medida que se realizaban los flujos de trabajo frente a otros escenarios de carga. Una vez finalizadas las pruebas, se reunieron y analizaron los resultados para identificar tanto los cuellos de botella como los componentes con exceso de recursos del sistema. Esta información se utilizó para identificar los componentes del sistema que debían ampliarse, reducirse o eliminarse antes de repetir las pruebas.

Las pruebas manuales de la experiencia del usuario se llevaron a cabo mediante la captura de grabaciones de pantalla de los probadores del flujo de trabajo para garantizar que los usuarios del sistema pudieran completar sus flujos de trabajo de forma productiva.

Para obtener más información, consulte cómo diseñar una estrategia de pruebas eficaz.

Ritmo del flujo de trabajo

Este estudio de prueba aplicó un modelo de ritmo a los flujos de trabajo probados. El modelo de ritmo muestra cómo la prueba pretende simular el ritmo de trabajo en una organización de administración de parcelas, donde los flujos de trabajo se realizan como un cierto número de operaciones por hora a través de un equipo de recursos de personal. Este planteamiento se basó en las aportaciones de los clientes de Esri y tenía como objetivo la correlación con el escenario de clientes de administración de parcelas de tamaño mediano en el que se basaban los datos.

Durante el periodo de prueba de una hora, los flujos de trabajo se distribuyeron y escalonaron para evitar que se iniciaran simultáneamente, permitiendo al mismo tiempo cierto solapamiento, con el fin de reproducir cómo se desarrollan las tareas en entornos reales. En el modelo de ritmo que se muestra a continuación, puede verse cómo se especificó el ritmo de cada flujo de trabajo y el número de operaciones por hora, que en conjunto definen la “carga de diseño” del sistema.

A continuación, se incrementó la carga multiplicando los flujos de trabajo hasta un punto en el que el sistema dejara de ser capaz de ofrecer respuestas aceptables o de soportar la ejecución correcta de los flujos de trabajo o, en este caso, hasta un punto lo suficientemente alto como para validar que el sistema funcionaría para el tipo de organización previsto. Tenga en cuenta que el modelo de ritmo de flujo de trabajo aplicado en este estudio de prueba podría no corresponderse con el uso diario típico en su organización.

Herramientas de pruebas de rendimiento

Dado que ArcGIS es un sistema de varios niveles, las pruebas de rendimiento 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. Se grabaron las solicitudes de ArcGIS Pro y se reprodujeron para simular la carga, además de los flujos de trabajo manuales que se realizaron para evaluar la experiencia del usuario final. También se utilizaron Windows Performance Monitor y ArcGIS Monitor para monitorizar el aprovechamiento de los recursos en diferentes componentes.

Para más información, consulte Herramientas de pruebas de rendimiento.

Resultados de las pruebas

Esta arquitectura se validó con pruebas de carga automatizadas y con usuarios manuales en tres escenarios, y puede ver los resultados de cada uno de ellos a continuación. A un alto nivel, los resultados de las pruebas muestran que, tal y como está implementado, el sistema cuenta con los recursos adecuados para admitir cargas desde la carga de diseño hasta 8 veces la carga de diseño. Las pruebas también reforzaron la importancia de una aplicación y una configuración del sistema adecuadas para el rendimiento.

Escenario de prueba: Carga de diseño

Observations:

• El sistema admitió la carga
• Los servidores de alojamiento (flujos de trabajo de visualización) tenían una media de utilización de CPU inferior al 30% (líneas naranjas)
• Los servidores de parcelas (flujos de trabajo de edición) registraron una utilización media de CPU inferior al 40%
• SQL Server muestra una utilización de CPU muy baja, normalmente por debajo del 15%
• El pico en la utilización del disco en la instancia de SQL Server puede atribuirse a un proceso de Windows en segundo plano (líneas doradas)
• Las solicitudes concurrentes muestran que, a lo largo del periodo de prueba, el sistema admitió aproximadamente 3 solicitudes concurrentes de visualización (rojo) y 1 solicitud concurrente de edición (azul) en un momento dado

Escenario de prueba: 4 veces la carga de diseño

Observations:

• El sistema soportaba la carga, con aumentos marginales de utilización de recursos entre componentes
• Los servidores de alojamiento registraron, por lo general, una utilización media de CPU inferior al 40%
• Los servidores de parcelas registraron, por lo general, una utilización media de CPU inferior al 50%
• SQL Server generalmente se mantenía por debajo del 40% de utilización de la CPU
• Los picos periódicos en la utilización del disco pueden atribuirse al inicio de los flujos de trabajo o a pasos concretos dentro de ellos. En concreto, el pico observado entre las 15:10 y las 15:20 está asociado al flujo de trabajo Summarize Parcels, en el que se abren varios paneles al mismo tiempo
• Las solicitudes concurrentes muestran que el sistema soporta una media de 10 a 15 solicitudes concurrentes de visores y de editores durante todo el periodo de prueba, con picos mayores de solicitudes de visualización concurrente que cierran muy rápido.

Escenario de prueba: 8 veces la carga de diseño

Observations:

• El sistema soporta la carga, con aumentos esperados en la utilización de recursos entre componentes
• Los servidores de alojamiento se mantienen, por lo general, por debajo del 50% de utilización de CPU.
• Los servidores de parcelas se mantienen, por lo general, por debajo del 50% de utilización de CPU
• SQL Server muestra aumentos significativos en la utilización de recursos, alcanzando de forma constante alrededor del 60% de utilización de CPU.
• Las solicitudes concurrentes muestran que el sistema soporta de forma constante picos de 35 solicitudes concurrentes de visualización y una media de dos solicitudes concurrentes de edición durante el periodo de prueba.
• El pico de solicitudes de lectura a las 20:20 corresponde al inicio del flujo de trabajo Summarize Parcels.

Configuración de la instancia del servicio

Además del uso de recursos de las máquinas virtuales, también monitorizamos la utilización de ArcSOC en cada ejecución de prueba para comprender mejor si los servicios estaban correctamente ajustados. En todas las ejecuciones de hasta 8 veces la carga de diseño, los ArcSOC ocupados se mantuvieron muy por debajo del máximo (16), lo que indica que habíamos configurado más instancias de mapa de las necesarias para esas cargas. Si se tratara de un entorno de producción con cargas inferiores a 8 veces la carga de diseño, podríamos optar por reducir el tamaño de las máquinas del servidor de alojamiento y del servidor SIG para ahorrar costes. Esto supone que monitorizaríamos la utilización de ArcSOC junto con la CPU y la memoria del servidor para saber cuándo es necesario escalar a fin de satisfacer la demanda. Además, tendríamos que asegurarnos de no sobrecargar esas máquinas, ya que cada ArcSOC consume cierta cantidad de memoria y cada ArcSOC ocupado utiliza una CPU virtual.

En el diagrama siguiente puede observarse que, en determinados momentos, los 16 ArcSOC están ocupados en el sitio del servidor de alojamiento con una carga equivalente a 8 veces la carga de diseño. Cuando todos los ArcSOC están ocupados, es de esperar que aumenten los tiempos de espera del servicio, tal como observamos. Sin embargo, el servidor de parcelas (a la derecha) muestra una menor utilización de ArcSOC, alcanzando solo un máximo de 9 en uso de los 16 configurados.

El pico inicial en el servidor anfitrión (izquierda) fue causado por el inicio de los cuadros de mando al inicio de las pruebas. Hemos corregido el ritmo del flujo de trabajo para futuras pruebas, repartiendo los arranques de los cuadros de mando en varios minutos para reflejar mejor escenarios reales.

• Para saber más, consulte este blog donde se detalla el arte y la ciencia de la optimización de ArcSOC.

Experiencia de usuario: tiempos de flujo de trabajo manual

Además de los flujos de trabajo automatizados, también observamos la experiencia del usuario capturando grabaciones de pantalla de los evaluadores de los flujos de trabajo y extrayendo de esas grabaciones la duración de los flujos de trabajo, es decir, cuánto tardaban los usuarios en completar todos los pasos de un flujo de trabajo. Esta práctica tiene como objetivo garantizar que los usuarios del sistema puedan completar sus flujos de trabajo de forma productiva.

Como puede verse en el gráfico siguiente, los tiempos registrados de los flujos de trabajo son, en gran medida, consistentes, con solo variaciones menores en todos los escenarios de prueba. Esto nos indica que el sistema puede soportar el aumento de la carga sin afectar negativamente la percepción de la capacidad de respuesta del sistema por parte de los usuarios finales.

Experiencia de usuario: tiempos de pasos del flujo de trabajo manual

Además de los flujos de trabajo en sí, también capturamos los tiempos de los pasos clave de todos los flujos de trabajo. Esto representa el tiempo medio que se tarda en completar un paso determinado de cada flujo de trabajo mientras el sistema estaba bajo carga. En el gráfico de abajo se puede ver un ejemplo del flujo de trabajo de fusión de parcelas, donde el tiempo que se tarda en completar cada paso fue muy uniforme en todos los escenarios de carga. Este patrón, con una variabilidad menor, es consistente en todos los flujos de trabajo.

Conclusiones y puntos clave

Estas pruebas se realizaron en un entorno de pruebas, no en un sistema de producción. Su sistema probablemente difierirá en flujos de trabajo, configuración o diseño. Por ejemplo, en Azure, normalmente no se utiliza Web Adaptor (asumiendo SAML) y App Gateway distribuye la carga directamente a los servidores. No obstante, puede extraer enseñanzas de estos enfoques y resultados de prueba para sus propios fines:

• Diseñar el sistema con criterios de observabilidad proporciona información de gran valor para ajustar correctamente el rendimiento en relación con los costes de infraestructura, además de respaldar otras actividades críticas, como la resolución de problemas.
• Supervise los recursos de servidor de sus sistemas, la utilización de ArcSOC y los tiempos de finalización de los flujos de trabajo, tanto durante las pruebas (en un entorno de ensayo/pruebas) como en producción.
• Busque posibles desajustes entre los recursos disponibles y su nivel de utilización. Por ejemplo:
  • Con una carga equivalente a 8 veces nuestra carga de diseño, el sitio del servidor de alojamiento parece estar correctamente dimensionado para este volumen de solicitudes. Sin embargo, los servidores SIG (servidores de parcelas) todavía tienen una cantidad considerable de recursos sin utilizar.
  • Existen varias oportunidades para reducir la infraestructura y ahorrar costes manteniendo el mismo rendimiento y la misma experiencia de usuario.
  • También existen oportunidades potenciales para reconfigurar los ArcSOC y distribuirlos de forma más adecuada para compatibilizar nuestros flujos de trabajo.