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.
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.
Los distintos flujos de trabajo se distribuyeron a lo largo de un periodo de prueba de una hora y se escalonaron para evitar que comenzaran al mismo tiempo, a la vez que se superponían entre sí como también lo harían los flujos de trabajo del mundo real. Este desglose global del ritmo del flujo de trabajo se considera la «carga de diseño» a la que está sometido el sistema. 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.

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.
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.

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.


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.

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.
