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. Para este estudio de prueba, el énfasis del planteamiento de las mismas se centró en el rendimiento del sistema y 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 compañía, 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 compañías eléctricas pequeñas y medianas 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. Esta carga está destinada a representar la actividad de una organización con 15 editores de ArcGIS Pro y 200 usuarios web de ArcGIS. Sin embargo, la carga de diseño está determinada en realidad por el número de operaciones realizadas por hora.

A continuación, la carga se incrementó multiplicando los flujos de trabajo hasta un punto en el que el sistema ya no era capaz de proporcionar respuestas aceptables ni de admitir flujos de trabajo correctos. 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 cuatro 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. En cada escenario, el aprovechamiento del sistema aumenta proporcionalmente a la carga.

Escenario de prueba: Carga de diseño

• El sistema admitió la carga con un bajo uso general de recursos

• No se utilizó ArcGIS Data Store (relacional): se accedió al mapa base como un servicio de teselas vectoriales.

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

• El sistema admitió la carga
• Los servidores de alojamiento funcionaban generalmente por debajo del 10 % de CPU
• Los servidores SIG funcionaban generalmente por debajo del 20 % de CPU
• El aprovechamiento de la CPU de PostgreSQL se mantuvo por debajo del 20 %.

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

• El sistema admitió la carga
• Los servidores de alojamiento funcionaban generalmente por debajo del 20 % de CPU
• Los servidores SIG funcionaban generalmente por debajo del 35 % de CPU
• El aprovechamiento de la CPU de PostgreSQL se mantuvo por debajo del 40 % con un par de picos en torno al 65 %.

Experiencia de usuario - Tiempos de flujo de trabajo conducidos

Mientras el sistema estaba bajo carga, se capturaron los tiempos de flujo de trabajo que experimentaban los usuarios. Esto representa el tiempo que se tardó en completar todos los pasos enumerados en los flujos de trabajo. Los tiempos de flujo de trabajo realizados son constantes hasta que el sistema se sobrecarga a 10 veces la carga de diseño.

Experiencia de usuario - Tiempos de paso del flujo de trabajo realizados

Mientras el sistema estaba bajo carga, se capturaron los tiempos de flujo de trabajo de los pasos clave en las ocho cargas de trabajo. Representa el tiempo medio que se tardó en completar un paso determinado.