Pruebas previas

Las pruebas previas son un paso de nuestro proceso destinado a mejorar los resultados de nuestras pruebas formales. Las pruebas previas sirven como una oportunidad para:

  • Identificar los cuellos de botella del sistema que podrían obstaculizar el rendimiento y la usabilidad del sistema bajo carga
  • Experimentar con otros ajustes y configuraciones de forma iterativa
  • Optimizar el proceso más formal de pruebas de carga

La arquitectura física inicial era casi idéntica a la de un sistema de administración de información de redes fundamental probado anteriormente y configurado con SAP HANA, con la única adición de un extremo VPN del cliente AWS para permitir la conexión de dispositivos móviles. Durante las pruebas previas, determinamos que el sistema no soportaría la carga prevista con las cargas de trabajo adicionales que se muestran a continuación. A continuación, se ajustó la arquitectura de forma apropiada, tal y como se describe en la arquitectura física. Puede ver los resultados finales de la prueba después de realizar estas modificaciones en la sección de resultados de la prueba.

Nota:

Una práctica recomendable es probar y validar su sistema cada vez que se introduzcan cambios, como nuevos flujos de trabajo o aumentos de la carga de trabajo, con el fin de identificar posibles impactos en el sistema antes de que se introduzcan en un entorno de producción.

Prueba previa con 4 veces la carga de diseño

El sistema se probó por primera vez con flujos de trabajo básicos de administración de información de redes que se ejecutaban sin flujos de trabajo móviles, como se muestra en el lado izquierdo de la siguiente figura. A excepción de un pico en ArcGIS Web Adaptor 02 al inicio de la prueba, atribuido a la instalación de actualizaciones de Windows Defender, el aprovechamiento de los recursos es relativamente bajo.

Compárelo con el lado derecho de la figura, que ilustra cómo agregar flujos de trabajo móviles además de 4 veces la carga provoca un uso significativo de la CPU en las instancias de ArcGIS Web Adaptors y Portal for ArcGIS. Los ArcGIS Web Adaptors se están saturando, lo que provoca que el procesamiento de las solicitudes se ralentice o se agote el tiempo de espera. Los cuatro servidores SIG y la base de datos también muestran un mayor uso de la CPU (naranja) y del disco (dorado). Esto se debe al paso de descarga de los flujos de trabajo sin conexión, donde un gran número de trabajadores móviles está descargando el área sin conexión de 2,66 GB.

Resultados de las pruebas comparativas entre 4 veces la carga sin dispositivos móviles y con dispositivos móviles

Las solicitudes pendientes solo para la carga fundamental que se muestran a continuación (lado izquierdo) ilustran el sistema que manipula la carga. Hay una pequeña acumulación de solicitudes pendientes al inicio de la prueba, que se estabiliza con un máximo de 19 editores y 11 visualizadores. Sin embargo, cuando se agrega la carga móvil adicional (lado derecho), las solicitudes aumentan a 42 de escritorio (visualizadores y editores) y 127 solicitudes móviles simultáneas antes de que se completen las descargas y la carga disminuya. Este patrón indica una ralentización durante la fase de descarga de la prueba, mientras los usuarios esperan a que se complete la descarga del área sin conexión.

Comparación de solicitudes simultáneas

Tamaños de instancia

Durante las pruebas previas, observamos tiempos de descarga prolongados en áreas sin conexión (2,66 GB de tamaño), que superaban los 30 minutos (véase la figura siguiente). Tras solucionar algunos problemas, determinamos que el problema se debía a un uso muy elevado de la CPU en las instancias de ArcGIS Web Adaptor y Portal for ArcGIS, lo que limitaba el rendimiento y provocaba que se agotara el tiempo de espera de las descargas. Para solucionar esto, se aumentaron las instancias de ArcGIS Web Adaptor de 2 vCPU a 8 vCPU y las instancias de Portal for ArcGIS de 4 vCPU a 8 vCPU.

Tiempos de descarga antes y después de la optimización

El paso de descarga de los flujos de trabajo desconectados se benefició especialmente del aumento del tamaño de las instancias de ArcGIS Web Adaptor y Portal for ArcGIS, con una reducción del tiempo de descarga del 41 %. Sin embargo, se trata de un exceso de capacidad cuando no hay un gran número de descargas en curso. En un entorno de producción, buscaríamos alguna forma de escalar esos componentes durante las horas punta y reducir el tamaño de las instancias cuando no sean necesarias para reducir los costes. Por lo tanto, optimizar los recursos y equilibrar el tamaño de los mapas sin conexión (haciéndolos lo más pequeños posible y cubriendo al mismo tiempo el área necesaria) es fundamental para lograr el equilibrio adecuado entre rendimiento y coste.

Configuración de la instancia del servicio

En ArcGIS Enterprise, las instancias de servicio de un servicio publicado se denominan procesos ArcSOC. Hay otros métodos para configurar ArcSOC con el fin de evitar largos tiempos de espera y una mala experiencia del usuario. En general, si el número de ArcSOC ocupados supera el máximo asignado a un servicio, los tiempos de espera aumentarán hasta que haya un ArcSOC disponible. Sin embargo, si el número máximo de ArcSOC en todos los servicios es superior al número de vCPU disponibles, los tiempos de espera también aumentarán, ya que todas las vCPU estarán ocupadas. Por lo tanto, es importante monitorizar y administrar el ratio de ArcSOC respecto a las vCPU disponibles, especialmente cuando se introducen cambios en el sistema.

Con 16 vCPU disponibles en los dos servidores de alojamiento, la configuración inicial de la instancia de servicio para el servicio de red de servicios móviles y el servicio de red de servicios de gas de solo lectura se estableció de la siguiente manera:

  • Mínimo: 8
  • Máximo: 8

Debido a que el servicio de red de servicios públicos de gas de solo lectura se ejecutó al máximo uso de ArcSOC durante la mayor parte de las pruebas previas, mientras que el servicio móvil tenía un exceso de ArcSOC libres, aprendimos que era necesario reconfigurar algunos servicios. Consulte las figuras siguientes para ver una comparación del aprovechamiento de ArcSOC antes y después de la optimización.

Observaciones de instancias de servicios de redes de servicios de solo lectura antes y después de la optimización

Observaciones de instancias de servicios de redes de servicios móviles antes y después de la optimización

Las instancias de servicio para el servicio de red de servicios móviles se redujeron de un mínimo y un máximo de 8 a un mínimo y un máximo de 6. Se aumentaron las instancias de servicio para el servicio de red de servicios de gas, pasando de un mínimo y un máximo de 8 a un mínimo y un máximo de 10. Tras el cambio, los gráficos muestran una distribución más uniforme entre ambos servicios y se ha mejorado considerablemente el tiempo de espera de los usuarios.

Resultados de las pruebas previas

Las pruebas previas del sistema de administración de información de redes original con las cargas de trabajo móviles agregadas ayudaron a identificar y corregir cuellos de botella y configuraciones incorrectas del sistema que, de otro modo, habrían afectado negativamente el rendimiento del sistema y la experiencia del usuario final en un entorno de producción. Nuestras pruebas previas dieron como resultado los siguientes ajustes del sistema, que se incorporaron antes de realizar las pruebas formales:

  • Las instancias de ArcGIS Web Adaptor se ampliaron de 2 vCPU a 8 vCPU.
  • Las instancias de Portal for ArcGIS se ampliaron de 4 vCPU a 8 vCPU.
  • El tamaño de las áreas sin conexión se optimizó para que fueran lo más pequeñas posible y, al mismo tiempo, cubrieran el área necesaria.
  • La configuración de ArcSOC se ajustó para proporcionar una distribución más uniforme del aprovechamiento y reducir los tiempos de espera tanto en el servicio de red de servicios móviles como en el servicio de red de servicios de gas.
Top