Pruebas de tiempo de respuesta: cómo medir el rendimiento de las API

⚡ Resumen inteligente

Las pruebas de tiempo de respuesta miden cuánto tarda un sistema en responder a una solicitud, desde que el usuario la envía hasta que la aplicación informa que ha finalizado. Esta guía abarca las métricas, los tres umbrales clave y las herramientas para medirlos.

  • 🇧🇷 Definición básica: El tiempo de respuesta abarca todo el proceso, desde que se envía la solicitud hasta que finaliza.
  • 📊 Tres métricas: El tiempo de respuesta promedio, el tiempo de respuesta máximo y la tasa de error, en conjunto, describen el comportamiento del sistema.
  • 🟢 0.1 segundo: La experiencia es instantánea, sin que el usuario perciba ninguna interrupción.
  • 🟡 1 segundo: El límite superior para un flujo de pensamiento ininterrumpido.
  • 🔴 10 segundos: El límite de la atención, aunque en la práctica los usuarios abandonan mucho antes.
  • 🧪 Método de medida: Integra un proceso de negocio con transacciones de inicio y fin dentro de una herramienta de pruebas de carga.

Prueba de tiempo de respuesta

¿Qué son las pruebas de tiempo de respuesta?

Prueba de tiempo de respuesta Mide el tiempo que tarda un nodo del sistema en responder a la solicitud de otro. Es el intervalo entre la llegada de una solicitud y la finalización del proceso correspondiente. Por ejemplo, si tienes una API y quieres saber exactamente cuánto tiempo tarda en ejecutarse y devolver datos en formato JSON, el tiempo de respuesta mide la respuesta del servidor a cada transacción o consulta.

El tiempo de respuesta comienza cuando un usuario envía una solicitud y finaliza en el momento en que la aplicación indica que la solicitud se ha completado.

Cómo medir el tiempo de respuesta

Para medir el tiempo de respuesta, podemos utilizar herramientas de prueba rodeando un proceso comercial importante con transacciones de inicio y finalización. Un proceso de negocio puede ser una acción o un conjunto de acciones que los usuarios realizan en la aplicación para completar una tarea de negocio como iniciar sesión en la aplicación o comprar un libro en Amazon.com

Prueba de tiempo de respuesta
Prueba de tiempo de respuesta

Para el mismo proceso para medir el tiempo de respuesta de una API, la respuesta variará ligeramente de una herramienta a otra. He aquí por qué

  • Paso 1) Método de cálculo de las métricas recopiladas por cada herramienta de prueba de tiempo de respuesta de API
  • Paso 2) Herramientas Simula la velocidad de carga y captura lo que puede marcar la diferencia en el tiempo de respuesta.
  • Paso 3) Elementos adicionales registrados al monitorear cargas de usuarios
  • Paso 4) Las métricas informáticas recopiladas por cada herramienta aumentan el tiempo de respuesta debido al alto consumo de recursos.
  • Paso 5) La arquitectura de las dos herramientas puede ser diferente

Tipos de métricas de respuesta

Métricas de tiempo de respuesta Explicación
Tiempo promedio de respuesta El tiempo promedio de respuesta es el tiempo promedio que se tarda en cada solicitud de ida y vuelta. El tiempo promedio de respuesta incluye el tiempo de carga de HTML, CSS, XML, imágenes, JavaArchivos de script, etc. Por lo tanto, el promedio se ve afectado cuando hay componentes lentos en el sistema.
Tiempo de respuesta pico El tiempo máximo de respuesta nos ayuda a encontrar componentes potencialmente problemáticos. Nos ayuda a encontrar todas las irregularidades en el sitio web o sistema donde una determinada solicitud no se maneja correctamente. Por ejemplo, es posible que se ejecute una consulta de base de datos grande que puede afectar el tiempo de respuesta. Esta consulta no permite que la página se cargue en el momento deseado.
Tasa de error La tasa de error es un cálculo matemático que muestra el porcentaje de solicitudes con problemas respecto al total de solicitudes. Este porcentaje contabiliza todos los códigos de estado HTTP que indican un error en el servidor. También contabiliza las solicitudes que caducan.

Tres umbrales de tiempo de respuesta que importan

En cualquier informe sobre tiempos de respuesta, dos cifras son las más importantes:

  • Tiempo promedio de respuesta
  • Tiempo de respuesta máximo o pico

En conjunto, muestran cuánto tiempo suele esperar un usuario y cuánto tiempo espera el usuario con peor suerte.

A continuación se muestran valores clave de ejemplo de prueba de tiempo de respuesta

Tiempo de Respuesta: Importancia
0.1 Segundo Es el tiempo de respuesta más preferido. Si el tiempo de respuesta es 0.1, los usuarios siempre sienten que la aplicación o el sistema responde instantáneamente y no sienten ninguna interrupción.
1.0 Segundo Este es el límite superior aceptado para una experiencia sin interrupciones. Es poco probable que los usuarios perciban alguna interrupción, aunque podrían experimentar cierta demora. Un tiempo de respuesta superior a 1 segundo podría interrumpir la experiencia del usuario.
10 Segundos Es un límite máximo después del cual el tiempo de respuesta supera el límite aceptable. Sin embargo, hoy en día, si el tiempo de respuesta supera los 6 segundos, el usuario abandonará ese sitio o abandonará la aplicación.

Siempre que sea posible, intente que el tiempo de respuesta esté entre 0.1 y 1 segundo. Los usuarios se adaptan a sistemas más lentos, pero la satisfacción disminuye drásticamente a partir de los 2 segundos, y cada segundo adicional aumenta la probabilidad de abandono.

Herramientas de prueba de tiempo de respuesta

Existen numerosas herramientas para probar el tiempo de respuesta. Dos de las más utilizadas son:

1) JMeter

Apache JMeter es una herramienta de prueba de carga de código abierto. Está diseñado para medir el rendimiento de los sitios web. Esta herramienta de prueba de carga se puede utilizar en la metodología DevOps.

JMeter

Características:

  • JMeter permite realizar pruebas de carga y rendimiento para varios tipos de servidores.
  • Esta herramienta de prueba de carga almacena sus planes de prueba en formato XML, lo que permite a los usuarios generar el plan de prueba utilizando un editor de texto.
  • La herramienta se puede utilizar para realizar tareas automatizadas y prueba funcional de las aplicaciones.

Enlace de descarga: Apache JMeter descargas


2) Corredor de carga

Loadrunner de Micro Focus es una herramienta de prueba de carga ampliamente utilizada. Es una de las mejores alternativas a JMeter que ofrece una interfaz de seguimiento y análisis fácil de usar con cuadros y gráficos en colores.

Corredor de carga

Características:

  • Admite pruebas continuas
  • LoadRunner puede funcionar eficazmente en varios entornos empresariales
  • Es posible ejecutar varios scripts de protocolo con Loadrunner
  • Integración con varias herramientas de desarrollo como Visual Studio, Jenkins, Selenium, etc.

Enlace de descarga: LoadRunner Profesional

Cómo encaja esta prueba en la familia de pruebas de rendimiento

Las pruebas de rendimiento son un término general. Las variantes que se describen a continuación solo difieren en la forma de la carga aplicada y la duración de la misma, razón por la cual suelen confundirse entre sí.

Tipo de prueba Patrón de carga Pregunta que responde
Prueba de carga Carga máxima prevista, corta duración ¿El sistema cumple sus objetivos en condiciones normales de tráfico máximo?
Prueba de esfuerzo Aumentado más allá de la capacidad hasta el fallo ¿Dónde falla y lo hace de forma elegante?
prueba de picos Aumento repentino y extremo, seguido de una remisión. ¿Sobrevive y se recupera de un impacto de tráfico?
Pruebas de resistencia La carga normal se mantuvo durante muchas horas. ¿El rendimiento se degrada con el tiempo?
Prueba de remojo Carga sostenida durante un período prolongado ¿Hay fugas de memoria o agotamiento de recursos?
Prueba de estabilidad Carga variable en función de las condiciones ¿El sistema sigue siendo fiable a medida que cambian las condiciones?
Pruebas de volumen Usuarios normales, volumen de datos muy grande ¿Puede soportar el crecimiento de la base de datos?

Las pruebas de resistencia y las pruebas de inmersión se suelen tratar como sinónimos. En el uso común, se utilizan para evaluar si ambas pruebas soportan una carga sostenida durante un período prolongado. Cuando los equipos las distinguen, las pruebas de resistencia se centran en si los tiempos de respuesta aumentan, mientras que las pruebas de estrés se centran en el consumo de recursos como la memoria, los descriptores de archivo y los grupos de conexiones. Generalmente, ejecutar una de estas pruebas proporciona evidencia para ambas.

Pruebas de tiempo de respuesta: Conclusiones clave

  • El tiempo de respuesta es el tiempo que tarda un nodo del sistema en responder a la solicitud de otro.
  • El tiempo promedio de respuesta en pruebas de rendimiento es el tiempo promedio que se tarda en cada solicitud de viaje de ida y vuelta.
  • El tiempo de respuesta máximo revela qué componentes son potencialmente problemáticos.
  • La tasa de error es un cálculo matemático que muestra el porcentaje de solicitudes de problemas.
  • Tres valores de tiempo de respuesta cruciales son: 0.1 segundos, 1.0 segundos y 10 segundos.
  • Dos de las herramientas de prueba de tiempo de respuesta más utilizadas son: JMeter y LoadRunner.

Preguntas Frecuentes

La latencia es el tiempo que tarda una solicitud en recorrer la red. El tiempo de respuesta incluye la latencia, además de todo el procesamiento y la representación del servidor. Una red rápida puede generar tiempos de respuesta deficientes si el servidor es lento.

El promedio oculta los valores atípicos. Un sistema con un promedio de 800 ms y un percentil 95 de 9 segundos está fallando a uno de cada veinte usuarios, y solo el percentil lo revela.

Procure que las acciones interactivas tarden menos de 1 segundo y que la carga completa de la página sea inferior a 2 segundos. Si se superan los 3 segundos, el abandono aumenta drásticamente, independientemente del límite teórico de 10 segundos.

La monitorización basada en IA establece una línea base normal para cada punto final y detecta automáticamente las desviaciones, sustituyendo los umbrales fijos que generan ruido durante los picos de tráfico previstos.

Sí. Los modelos entrenados con datos históricos de rendimiento pueden indicar qué cambios en el código podrían ralentizar un punto final. Confirme cada predicción con una prueba real.

Resumir este post con: