Estrategias recomendadas para pruebas de carga en un despliegue de ArcGIS Server
- Comience con un plan de prueba
La mayoría del software de pruebas puede generar algún tipo de informe una vez que la prueba ha finalizado. Este informe debe responder a las preguntas que planteaba el plan de prueba.
Por ejemplo:
a) ¿Podría el servicio ArcGIS utilizar toda la CPU (por ejemplo, limitado por CPU)?
b) ¿Podría el servicio ArcGIS entregar un rendimiento específico (por ejemplo, cierta cantidad de transacciones/seg)?
c) ¿Entregó el rendimiento un tiempo de respuesta promedio que cumplió con nuestro requisito de rendimiento?
Definir un propósito para una prueba ayuda a mantener el esfuerzo de prueba enfocado en un objetivo.
- Las pruebas deben realizarse contra aplicaciones sin errores o defectos mayores conocidos
Las pruebas de carga no deben usarse para probar funcionalmente un despliegue o aplicación.
Una aplicación debe pasar las pruebas de aseguramiento de calidad (QA) antes de que se realicen pruebas de carga.
Además, si una aplicación contiene errores mayores, tales deficiencias podrían tener un impacto medible en el rendimiento y escalabilidad de los servicios ofrecidos. Esto a su vez probablemente anularía los resultados de la prueba y potencialmente desperdiciaría tiempo, dinero y recursos.
- Interactúe con su aplicación (y servicios ArcGIS) antes de realizar pruebas de carga
Si usted es el único usuario en su sistema y los servicios ArcGIS responden muy lentamente, no hay necesidad de realizar una prueba bajo carga. El siguiente paso debería ser ajustar y optimizar los servicios ArcGIS para el rendimiento.
- Coordine la ejecución de la prueba
Muchas veces una prueba de carga se realiza en un entorno QA/Staging o Test pero ocasionalmente puede llevarse a cabo en Producción.
Cualquiera que sea el entorno, es importante recordar que a menudo, los servicios y recursos están siendo consumidos también por otros usuarios (y no solo por el equipo de pruebas de carga).
Para ayudar a evitar confusión y experiencias inesperadas, se recomienda encarecidamente coordinar la ejecución de cualquier prueba de carga con el personal apropiado.
Hacerlo puede ayudar a proporcionar una mejor experiencia para los usuarios reales y puede evitar ruido no deseado en una prueba de carga (por acciones que usuarios reales podrían estar realizando).
- Verifique que el entorno de prueba coincida con las expectativas
A veces el entorno Test podría estar reducido debido a diversas razones. Luego, con el tiempo, Test y Producción se convierten en entornos muy diferentes. En este caso, los resultados derivados del entorno Test tendrían poco significado en relación con cómo funcionará o escalará Producción.
Por ejemplo:
a) Si se espera que Producción esté desplegado usando una arquitectura Altamente Disponible entonces Test también debería estarlo
b) Si se espera que Producción utilice una geodatabase empresarial que contenga 500GB de datos vectoriales entonces Test también debería hacerlo
c) Si Producción usa ArcGIS Servers con 32 núcleos y los máximos de instancia del servicio están configurados a 32, entonces Test también debería hacerlo
Mantener los entornos Test y Producción sincronizados puede ayudar a proporcionar el mejor valor (y expectativa) sobre los resultados. En casos donde conscientemente no coincidan, tome nota antes de comenzar las pruebas y en cualquier conclusión derivada del entorno Test.
- Comience una prueba de carga en el paso 1
Usar 1 como paso inicial de carga puede ayudar en su análisis posterior a la prueba.
El paso 1 (o un hilo concurrente de prueba) representa el mejor escenario posible para su prueba. Esta es su línea base y es una buena referencia para entender qué tan bien o mal escaló el servicio ArcGIS conforme aumentó la presión (por ejemplo, cuando se agregaron hilos adicionales).
- Recolecte la utilización del hardware de todas las máquinas involucradas en la prueba
La mayoría de los frameworks de pruebas típicamente proporcionan la capacidad para recolectar la utilización del hardware desde los servidores y desde el cliente de prueba mismo. Esto puede ser valioso para entender el consumo de recursos e identificar cuellos de botella (por ejemplo, los recursos en el cliente de prueba también pueden ser un factor limitante).
Sin embargo, a pesar de contar con esta función en el software de pruebas, recolectar la utilización del hardware no siempre es posible debido a permisos o acceso a red (por ejemplo, conexión a través de firewalls/enrutadores).
Aunque obtener esta información directamente mediante un framework de pruebas es ciertamente conveniente, existen otras formas para lograr esta tarea. Usar herramientas gratuitas como PerfMon en Windows o dtstat en Linux para capturar estos datos es un paso adicional pero vale la pena. Una vez completada la prueba, aún se puede realizar análisis sobre los datos gráficos creados manualmente a partir del uso del hardware.
- Pruebe primero servicios individuales ArcGIS
Si una aplicación web específica usa más de un servicio ArcGIS, pruebe y ajuste cada uno por separado.
Este enfoque facilita identificar qué servicios pueden tener cuellos de botella o limitaciones que les impiden utilizar todo el hardware disponible.
Si un servicio ArcGIS no puede utilizar todo el hardware CPU disponible del ArcGIS Server, el evaluador/analista debe notificar a la persona apropiada que existe una oportunidad para ajustar el despliegue.
Además, evite comenzar el esfuerzo de pruebas con todo el flujo completo de la aplicación ya que puede ser difícil detectar posibles cuellos cuando muchos servicios ArcGIS son probados simultáneamente.
- Pruebe lo más físicamente cerca posible del despliegue
Trate de no hacer que la prueba "simule" Internet. Probar lo más físicamente cerca posible del despliegue puede ayudar a proporcionar la mejor comprensión sobre lo que puede entregar el hardware del servidor.
Introducir intencionalmente latencia en la red o ancho de banda pobre añadirá ruido a una prueba y dificultará reconocer toda la capacidad real de los servicios ArcGIS y los servidores donde se ejecutan.
- Duración del paso y duración total del test
Las pruebas no necesitan ejecutarse durante 8 horas para proporcionar información útil sobre el servicio ArcGIS en cuestión. Sin embargo, también se recomienda evitar ejecutar una prueba demasiado corta. Esto se reduce a elegir una duración adecuada para cada paso y para toda la prueba que proporcione la cantidad correcta de información. En otras palabras, se trata de registrar suficientes muestras para obtener un promedio "bueno".
La duración típica está ligada al tiempo de respuesta: un tiempo rápido puede entregar muchas solicitudes con un paso cargado de 5 minutos. Un tiempo lento podría necesitar un paso cargado de 15 minutos para registrar igual cantidad valores.
Como evaluador, puede que no siempre acierte con la duración del paso y test en su primera estimación y necesite ajustar y volver a ejecutar la prueba.
- Tenga cuidado con el nivel del registro (Log Level) en ArcGIS Server
Aunque los registros (logs) del ArcGIS Server pueden proporcionar mucha información para analizar, es importante entender que niveles altos como VERBOSE y DEBUG pueden ralentizar significativamente el rendimiento en sitios muy ocupados y no son configuraciones recomendadas para entornos Productivos. Mientras tanto, el valor WARNING (el predeterminado) ofrece el mejor rendimiento posible ya que solo registra advertencias y errores.
Sin embargo, una configuración FINE es un buen compromiso entre información analítica útil (como tiempos transcurridos en solicitudes dinámicas) y velocidad.
- Los servicios tradicionales ArcGIS pueden ajustarse dentro del servidor (ArcGIS Server)
Antes de realizar pruebas carga sobre un servicio tradicional (por ejemplo dedicado) ArcGIS para ajustarlo o entender cómo funciona, intente configurar su valor máximo ArcSOC instance al número disponible núcleos CPU en ArcGIS server.
Después reiniciar el servicio, esta configuración permitirá múltiples solicitudes simultáneas aprovechar al máximo hardware disponible y mostrarlo bajo su mejor luz (esto asume que el servicio está limitado por CPU).
style="padding-left : 30px;">Incrementar el valor máximo de la instancia ArcSOC también permitirá que el servicio utilice más CPU pero, a su vez, también más memoria. Por favor, asegúrese de que haya suficiente memoria disponible en la máquina ArcGIS Server para acomodar el ajuste. Si el servicio no está en alta demanda, las instancias adicionales quedarán inactivas (el valor predeterminado es 1800 segundos) y se apagarán para liberar memoria del servidor.<\/P>
De manera similar, aumentar el mínimo de una instancia de servicio (para que coincida con el máximo) es una buena estrategia para obtener un rendimiento predecible. Esto se recomienda para los servicios más populares, pero tenga en cuenta que dicha configuración siempre consumirá memoria (para ese servicio) ya que ninguna instancia se apagará después de que haya transcurrido el tiempo de inactividad.<\/P>
Los servicios compartidos también tienen configuraciones de instancia que podrían ajustarse. Sin embargo, si un servicio compartido es lo suficientemente popular como para ser probado con carga, debería ajustarse para ejecutarse como un servicio tradicional y dedicado.<\/P>
- No todos los servicios ArcGIS están limitados por CPU<\/STRONG><\/LI><\/UL>Si un servicio ArcGIS está limitado por CPU, significa que la cantidad de rendimiento que puede entregar (o la capacidad que puede soportar) está limitada solo por el número de CPUs en la(s) máquina(s) ArcGIS Server. En muchos sentidos, esto puede ser algo bueno.<\/P>Sin embargo, esto no siempre es así. A veces, puede haber cuellos de botella en otro hardware como la red, por ejemplo. Ocasionalmente, puede encontrarse un cuello de botella en un componente de software que puede ser por diseño o no intencionado.<\/P>Por lo tanto, la recopilación de métricas de hardware durante la prueba es muy importante. Observar la utilización de CPU, Memoria, Red y Disco puede proporcionar al evaluador/analista información vital para entender si hay algo que limita la escalabilidad del servicio ArcGIS Server y si es el hardware del servidor o del cliente de prueba.<\/P>Todo se trata del rendimiento (no de los usuarios)<\/STRONG><\/LI><\/UL>El rendimiento se mide, los usuarios se calculan... son dos artefactos diferentes de una prueba.<\/P>En una prueba, el rendimiento generalmente se define como transacciones/segundo (u operaciones/segundo), y este es un valor que debe ser medido por el software cliente de prueba. Por otro lado, la definición de un "usuario" puede variar pero suele calcularse a partir del rendimiento.<\/P>Dado que el rendimiento se observa directamente a partir de los resultados de una prueba de carga, es una de las mejores métricas para determinar la escalabilidad de una implementación.<\/P>En una nota relacionada, un hilo de prueba (por ejemplo, el elemento que aumenta en correspondencia con más presión añadida a una prueba de carga) tampoco es lo mismo que un usuario. El número de hilos de prueba utilizados y su duración generalmente se configuran en la definición de carga escalonada de una prueba.<\/P>Verifique que la prueba fue exitosa<\/STRONG><\/LI><\/UL>La finalización de una prueba no significa necesariamente que fue "buena" y capaz de responder exitosamente las preguntas del plan de pruebas. Es importante verificar y validar que la prueba estaba enviando las solicitudes correctas donde debía y obteniendo las respuestas esperadas.<\/P>Un control rápido manual de calidad (QC) sobre la composición de las solicitudes en la prueba puede ayudar con lo primero.<\/P>Mientras que monitorear la longitud promedio del contenido (por respuesta) puede ayudar con lo segundo.<\/P>La mayoría del software de pruebas proporciona un "por qué" para capturar la longitud promedio del contenido (o algo similar). La regla general es que el valor promedio para esta métrica debe mantenerse relativamente constante durante toda la prueba. Si aumenta o disminuye drásticamente, se recomienda una investigación adicional ya que la respuesta esperada para las solicitudes podría no estar regresando (por ejemplo, errores en lugar de contenido imagen o json) o si la respuesta es válida pero muy variable podría necesitarse un diseño diferente para la prueba.<\/P>Además, es importante determinar si las solicitudes mismas fueron exitosas (por ejemplo HTTP 200). Algunos softwares pueden permitir al analista configurar verificaciones de validación sobre las respuestas dentro misma de la prueba. Dicho esto, el perfilado del métrico longitud promedio del contenido usualmente proporciona una vista más precisa sobre la respuesta esperada del servidor.<\/P>Los resultados de las pruebas no garantizan soporte para X número de usuarios<\/STRONG><\/LI><\/UL>Los resultados solo validan el flujo probado. Este flujo probado mostrará rendimiento para un tipo específico de solicitud con un tiempo correspondiente de respuesta. No promete ni garantiza que la implementación soportará X número de usuarios.<\/P>Recuerde, la definición de usuario puede variar y significar cosas diferentes para distintas implementaciones.<\/P>Evite probar recursos compartidos como ArcGIS Online o Google Maps<\/STRONG><\/LI><\/UL>Las ofertas gratuitas y públicas del servicio ArcGIS Online o Google Maps están ahí para la "comunidad". Tales recursos son bastante robustos y escalables pero no pueden ser ajustados en rendimiento respecto a cada usuario.<\/P>Como no forman parte directamente de una implementación on-premise, deben considerarse un recurso "externo". Como resultado, las solicitudes hacia ellos deben eliminarse en una prueba de carga ya que esta debe centrarse únicamente en las capacidades del propio hardware.<\/P>Resultados repetibles en pruebas<\/STRONG><\/LI><\/UL>Si los resultados para una prueba de carga contra un servicio ArcGIS Server muestran líneas con tendencias similares entre ejecuciones (por ejemplo, se logra el mismo rendimiento alrededor del mismo punto durante la prueba), generalmente se considera que el recurso es "estable". Poder repetir los resultados para una prueba es una buena característica.<\/P>Cuando los resultados no son inmediatamente repetibles, el evaluador/analista debe profundizar e intentar entender el comportamiento inconsistente. Podría ser que el hardware estaba siendo usado para atender solicitudes distintas a la prueba (por ejemplo otro usuario en el sistema). O si la implementación estaba en infraestructura compartida (por ejemplo virtualización), el hardware subyacente estaba siendo utilizado para otro propósito (otras máquinas virtuales ejecutaban tareas intensivas en recursos). Para casos como este, realizar las pruebas durante horas no pico podría arrojar resultados más reproducibles mostrando que el servicio tiene potencial para ser estable.<\/P>El diseño de pruebas/flujos debe ser realista y basado en lo esperado por un usuario<\/STRONG><\/LI><\/UL>Evite teorías y proyecciones; simplemente concéntrese en cómo debería usarlo el usuario...el flujo anticipado.
Las pruebas de carga pueden ser fáciles pero también fácil expandir su alcance incluyendo escenarios innecesarios o poco probables.<\/P>Entienda el valor<\/STRONG><\/LI><\/UL>Muchas veces, el camino hacia una buena y útil prueba es tan importante como la propia prueba. Como analista esto le ayuda:<\/P>a) Validar los procedimientos de prueba<\/P>b) Tener mayor capacidad para explicar los resultados lo cual a su vez hace valiosa su prueba<\/P> 1) Algunas personas no solo pedirán resultados sino también análisis y conclusiones<\/P> 2) Esté preparado para respaldar estas conclusiones con datos<\/P>Manténgalo simple<\/STRONG><\/LI><\/UL>A veces los esfuerzos más informativos en pruebas son simples y no excesivamente complejos.<\/P>
