Sugerencias de pruebas de rendimiento

Divida el script en escenarios configurables, que deberían cubrir, por ejemplo:

• Abrir página principal

• Abrir página de categoría (PLP)

• Ver productos simples (PDP): 2 bucles dentro de cada iteración

• Ver productos configurables: 2 bucles dentro de cada iteración

  • Por ejemplo, establezca los pasos anteriores en 60 % del tráfico

• Búsqueda de productos

  • Por ejemplo, configure la búsqueda en el catálogo en el 37 % del tráfico

• Carro y cierre de compra

  • Por ejemplo: un usuario que completa la parte del script de carro de compras y cierre de compra debe tener de forma predeterminada una tasa de conversión del sitio de comercio electrónico estándar del sector de alrededor del 3 %
  • Dado que el flujo de cierre de compra no se almacena en caché y suele ser una operación que consume muchos recursos, establecer una cifra demasiado alta para el número de personas que completan pedidos en comparación con el número de exploradores del sitio daría un resultado poco fiable para el volumen de tráfico que podría gestionar el sitio.

Limpie todas las cachés antes de cada ejecución de prueba:

• AEM La caché de Dispatcher debe limpiarse por completo
• La caché interna y de Fastly de Adobe Commerce debe vaciarse y limpiarse por completo, esto se puede hacer a través del control de caché en el administrador de Adobe Commerce.

Incluir un período de rampa en la prueba Jmeter: No tener un período de rampa establecido significa que no hay una rampa gradual del tráfico y no hay oportunidad para que el sitio almacene en caché ninguna de las páginas y los componentes de la página más visitados. En la vida real, sería inusual que todo el tráfico pico llegara a un sitio completamente sin caché exactamente al mismo tiempo, por lo tanto, se debe incluir un período de rampa en los scripts de prueba Jmeter para permitir que la caché se acumule como ocurriría en un sitio de comercio electrónico real.

Se debe utilizar un "Tiempo de espera" entre cada paso de una iteración: en realidad, un usuario no pasaría inmediatamente a la siguiente página del sitio durante su recorrido; habría un tiempo de espera mientras leía la página y decidía su siguiente acción.

Configurar los grupos de hilos para que se reproduzcan infinitamente, pero durante un tiempo establecido de x (p. ej., 60 minutos), dará una prueba repetible, con tiempos de respuesta medios comparables con ejecuciones de pruebas anteriores. Esto significa que después del período de ampliación establecido, habrá el número de destino de usuarios virtuales ejecutándose simultáneamente y esto continuará durante el tiempo de bucle establecido.

La mediana de tiempo debe utilizarse para proporcionar una mejora/disminución del tiempo medio de respuesta, no del promedio. Si hay varios resultados Edge que tardan mucho más que los otros resultados, esto distorsionaría este resultado promedio, pero lo que nos interesa en el tiempo de respuesta del usuario final para la mayoría de los usuarios, que es más adecuado para la mediana de la medición.

Los recursos incrustados no se recopilan de forma predeterminada en jmeter (por ejemplo, JS, CSS y otros recursos descargados cuando un usuario real visita la página). Esto se puede habilitar, pero solo para el dominio que está probando: las llamadas de recursos externos deben excluirse (por ejemplo, no queremos incluir los tiempos de respuesta de servicios alojados externamente, por ejemplo, código de google analytics, ya que no tenemos control sobre ellos).

El Administrador de caché HTTP debe estar habilitado, lo que permite a Jmeter almacenar en caché los elementos de página durante un recorrido, como lo haría un recorrido real del usuario durante su navegación por el sitio web en su propio navegador. Durante su recorrido por el sitio, el explorador del usuario descargaría el recurso incrustado relacionado solo una vez y, a continuación, el explorador del usuario lo almacenaría en caché. Además, si el mismo usuario regresa al sitio algún tiempo después de su visita original, podría seguir siendo la caché en la que se almacenan esos recursos.

Los oyentes deben mantenerse dentro de las ejecuciones de prueba de carga reales (por ejemplo, "Ver árbol de resultados" e "Informe agregado"). Incluirlo en la ejecución de pruebas de carga real no GUI puede afectar a los resultados de rendimiento que Jmeter informa, ya que los recursos se utilizan durante la ejecución de pruebas reales para generar los informes. Estos oyentes se eliminaron del script de prueba para reemplazarlos con un archivo de resultados JTL, que luego se puede procesar con la funcionalidad Report Dashboard de Jmeter.

Un tiempo de respuesta objetivo para evaluado de modo que la "puntuación Apdex" del informe del panel se pueda utilizar como una forma rápida de medir el efecto de los cambios en el rendimiento entre ejecuciones de prueba. La puntuación Apdex se basa en una cierta cantidad de personas que pueden acceder al sitio en un tiempo tolerable . Si el tiempo de respuesta es superior a una determinada cantidad "frustrante", esto reduce la puntuación. Los tiempos se pueden establecer usando los parámetros "apdex_completed_threshold" y "apdex_tolerated_threshold".

Establezca como objetivo una métrica "Pedidos por hora" para presentarla a los usuarios empresariales, no un recuento de usuarios virtuales. "Usuarios virtuales" puede ser un tema complejo para comprender qué mide la prueba en la vida real. Al calcular la tasa de conversión del sitio, los pedidos por hora, el tiempo promedio que un usuario pasa en el sitio y el tiempo de reflexión entre cada carga de página, se pueden utilizar cálculos estándar del sector para presentar diferentes escenarios de prueba de carga basados en los pedidos por hora que se van a lograr.

Por último, el servidor de prueba Jmeter debe ejecutarse en un servidor geográficamente cerca de donde proviene la mayor parte del tráfico de usuario y donde está alojada su infraestructura en la nube. Esperamos que estos sean los mismos.