Conclusiones y puntos clave

A lo largo de las cinco ejecuciones de prueba, quedó claro que la instancia de base de datos con recursos insuficientes en la primera ejecución degradó de forma apreciable el rendimiento del sistema y la experiencia del usuario. Una vez que la instancia de base de datos se dimensionó correctamente para nuestras cargas de trabajo, las proporciones ArcSOC:vCPU tuvieron un impacto menor en los tiempos de ejecución de los flujos de trabajo. Si observamos la tabla siguiente, podemos ver que la proporción ArcSOC:vCPU de 1:1 impuso algunos tiempos de espera adicionales (0,246 s) en los flujos de trabajo de visualización, pero no afectó de forma significativa a los flujos de trabajo de edición (véase P99 Waits HS). Esto probablemente se deba a que los ArcSOC estén ocupados en el servidor host.

La proporción 2:1 produjo tiempos de ejecución de los flujos de trabajo casi idénticos, sin esperas significativas, pero sí presentó una alta utilización de memoria en el servidor SIG de Utility Network (82%). La proporción 2:1 es demasiado alta para estos flujos de trabajo de edición versionada, en los que el número máximo de ArcSOC en el servidor SIG de Utility Network solo alcanza 7. Por lo tanto, al aumentar los ArcSOC en el servidor SIG de Utility Network, solo se están desperdiciando recursos del servidor. Sin embargo, el servidor host, que daba soporte a flujos de trabajo de solo visualización, admitía fácilmente la proporción 2:1. El servidor SIG de Utility Network necesita más memoria para soportar proporciones de 2:1 o superiores. Con una proporción de 4:1, el servidor host también necesita más memoria.

Utilización de recursos

Concluimos que añadir agregar más instancias de servicio no se tradujo en una mejor experiencia de usuario para los editores, aunque puede mejorar la capacidad de respuesta en nuestros flujos de trabajo de visualización al reducir los tiempos de espera. Observamos que incluso los ArcSOC que no estaban en uso seguían consumiendo recursos del servidor. La tabla anterior muestra que los tiempos de los flujos de trabajo aumentan ligeramente a medida que se incrementa la proporción ArcSOC:vCPU.

Esto implica que los ArcSOCs adicionales disponibles no eran necesarios para soportar las solicitudes de los usuarios y consumían innecesariamente recursos del sistema (principalmente memoria). La tabla anterior confirma que los flujos de trabajo de edición no aprovecharon los ArcSOCs adicionales, pero sí los flujos de trabajo de vista con muchas más operaciones por hora. Por lo tanto, para nuestro sistema, una proporción de 2:1 de ArcSOCs a vCPU era la más óptima para servicios solo de visualización en el servidor host, mientras que 1:1 es la más adecuada en el servidor SIG de Utility Networt.

Puntos clave

• Una instancia de base de datos con pocos recursos afectó negativamente a todo el sistema:

  • Para nuestro sistema, determinamos que un tamaño mayor de instancia de geodatabase (16 vCPU) era fundamental

  • Los ArcSOCs, la CPU de servidor SIG y los adaptadores web estaban ocupados, haciendo que los problemas de rendimiento parecieran ser a nivel de sistema

  • Los tiempos de ejecución de los flujos de trabajo tardaban aproximadamente el doble en completarse con una base de datos infradimensionada

  • Una base de datos con recursos insuficientes afectó al rendimiento de forma significativamente mayor que unas instancias de mapa mal configuradas

  • Simplemente aumentar los recursos de la base de datos mejoró enormemente el comportamiento y el rendimiento del sistema

• Con una base de datos adecuadamente dotada de recursos, aumentar la proporción de ArcSOCs (instancias de servicio de mapas) respecto a vCPU no mejoró la experiencia del usuario final ni los tiempos de ejecución del flujo de trabajo

• Añadir instancias de servicio innecesarias puede afectar negativamente al sistema al consumir recursos adicionales innecesarios

• Aumentar el número de instancias de mapas en ejecución afectará a la utilización de la memoria del servidor SIG, incluso cuando no estén ocupadas

• La separación de cargas de trabajo sigue siendo importante: los servicios de entidades que exponen datos versionados consumirán más memoria del servidor SIG que los servicios de solo visualización

  • Los recursos disponibles en la instancia de base de datos (CPU, RAM y E/S de disco) mejoraron de forma significativa la capacidad de todo el sistema para soportar la carga

• Como mínimo, supervise la CPU de la base de datos, el uso de ArcSOC, los recursos del servidor SIG y la experiencia del usuario para identificar la configuración óptima de su sistema, especialmente después de realizar cualquier cambio