El rendimiento y la estabilidad son primordiales al construir y mantener APIs. El rendimiento de la API impacta directamente en la experiencia del usuario y la disponibilidad del sistema, haciendo que las pruebas de rendimiento exhaustivas sean esenciales.
¿Qué son las pruebas de rendimiento de APIs?
Las pruebas de rendimiento de APIs típicamente involucran la simulación del comportamiento real del usuario, pruebas de estrés y pruebas de carga para evaluar la estabilidad del sistema y las métricas de rendimiento.
Antes de realizar pruebas de rendimiento, se recomienda realizar pruebas funcionales en la API para asegurar que todas las APIs funcionen correctamente como se espera. Las pruebas funcionales ayudan a identificar y rectificar problemas funcionales, mientras que las pruebas de rendimiento se enfocan en evaluar el comportamiento de la API bajo alta carga. Solo las APIs funcionalmente sólidas producen resultados de pruebas de rendimiento significativos, proporcionando una base confiable para una mayor optimización del rendimiento.
¿Cómo realizar pruebas de rendimiento en Apidog?
Esta guía te guiará a través del aprovechamiento de la función "Prueba de rendimiento" de Apidog para evaluar el rendimiento de tu API.
Paso 1: Orquestando escenarios de pruebas de rendimiento
Antes de iniciar las pruebas de rendimiento, necesitas crear casos de prueba. Puedes importarlos desde APIs existentes o casos de uso de APIs, o definir solicitudes personalizadas. Una vez que los pasos de la prueba estén listos, es aconsejable ejecutar una prueba funcional para asegurar que la API opere como se espera antes de proceder con las pruebas de rendimiento.
Paso 2: Configurando los ajustes de la prueba de rendimiento
En la sección "Tests" de Apidog, encontrarás un módulo dedicado para "Performance (Beta)". Aquí, puedes configurar varios ajustes para prepararte para la próxima prueba de rendimiento.
Opciones de configuración:
Especifica el entorno del servicio backend para las solicitudes durante la "Prueba de rendimiento". Por defecto, la configuración del entorno establecida para el proyecto actual se aplica automáticamente.
Los datos de prueba se refieren al conjunto de datos utilizado para iniciar solicitudes durante las pruebas de rendimiento. El uso de datos de prueba permite que cada usuario concurrente realice solicitudes con diferentes parámetros, simulando mejor el tráfico del mundo real.
- Para usar datos de prueba, haz clic en la pestaña "Test Data" y crea un nuevo conjunto de datos.
- Configura el conjunto de datos para el entorno correspondiente. Puedes añadir datos manualmente o importarlos en formato JSON o CSV. Guarda el conjunto de datos después de editarlo.
- En la página de detalles del paso de prueba, asocia variables con los datos de prueba.
- Cuando eliges asociar datos de prueba en una prueba de rendimiento, los usuarios concurrentes usarán las variables definidas en los datos de prueba para realizar solicitudes. Puedes elegir entre los modos "Aleatorio" y "Ordenado" para las pruebas.
Cada usuario concurrente selecciona aleatoriamente una fila de datos de los datos de prueba. Esto asegura que cada usuario obtenga datos únicos, garantizando una amplia cobertura en la prueba de rendimiento.
Coincidencia ordenada:
Cada usuario concurrente selecciona la siguiente fila de datos en secuencia de los datos de prueba. Ten en cuenta que si el número de usuarios concurrentes excede el número de filas en los datos de prueba, los usuarios excedentes no participarán en la prueba. Asegúrate de tener suficientes datos de prueba para soportar a todos los usuarios concurrentes en este modo.
- Usuarios concurrentes (Usuarios virtuales):
Las pruebas de rendimiento actualmente soportan la simulación de hasta 100 usuarios concurrentes. Estos usuarios simularán concurrentemente el comportamiento real del usuario en línea dentro de la duración de la prueba especificada, ejecutando repetidamente el escenario de prueba. Esto simula eficazmente escenarios de alta concurrencia para evaluar el rendimiento y la estabilidad de la API bajo un gran número de solicitudes de usuario.
- Tiempo de ejecución:
Define la duración total de la prueba de rendimiento. Cada usuario concurrente recorrerá continuamente todas las solicitudes de API definidas en el escenario de prueba dentro de este tiempo establecido. Actualmente, la duración máxima de la prueba soportada es de 60 minutos.
- Tiempo de aceleración:
En algunos casos, un gran número de usuarios no acceden al servicio instantáneamente, sino que aumentan gradualmente con el tiempo.
El tiempo de aceleración simula el aumento gradual en el tráfico de usuarios. En lugar de usar todos los usuarios concurrentes inmediatamente al inicio de la prueba, el número de usuarios aumenta linealmente durante un tiempo establecido (X minutos) hasta que alcanza el número total de usuarios concurrentes. Establecer X en 0 significa que todos los usuarios concurrentes se habilitarán para las pruebas de estrés desde el principio.
Después de configurar las opciones anteriores, guarda los ajustes y haz clic en el botón "Run" para iniciar la prueba de rendimiento.
Paso 3: Ejecutando la prueba de rendimiento
Al hacer clic en "Run" se inicia la prueba de rendimiento. La prueba de rendimiento de Apidog se origina desde el ordenador del usuario (no el servidor de Apidog) y utiliza los recursos de hardware del ordenador para ejecutar los pasos de prueba configurados, los datos de prueba y las solicitudes concurrentes.
Por lo tanto, necesitas considerar el rendimiento de tu ordenador y el comportamiento de otras APIs para determinar si el problema de rendimiento radica en la API que se está probando o en el ordenador que inicia la prueba. Si encuentras que el número de solicitudes iniciadas no aumenta independientemente del servidor o la API, es posible que necesites un ordenador más potente para realizar la prueba de rendimiento.
Una vez que comienza la prueba de rendimiento, Apidog proporciona un panel de visualización intuitivo para monitorear y mostrar indicadores clave de rendimiento en tiempo real. Esto incluye el número total de solicitudes para cada API, solicitudes por segundo, tiempo de respuesta promedio, tiempo de respuesta máximo/mínimo y tasa de fallos de solicitud.
Entendiendo las métricas de rendimiento:
El panel de visualización presenta datos completos para todo el escenario de prueba y datos de API individuales.
Datos completos:
- Solicitudes totales: Refleja el número total de solicitudes procesadas por la API durante la prueba. Un alto número de solicitudes totales es razonable en escenarios de usuarios a gran escala, pero asegúrate de que la API pueda manejar estas solicitudes de manera efectiva.
- Solicitudes por segundo: Un número alto indica que la API puede procesar un gran volumen de solicitudes en un corto tiempo, lo que significa un buen rendimiento. Un número bajo podría sugerir un cuello de botella en el rendimiento.
- Tiempo de respuesta promedio: Un tiempo de respuesta promedio bajo generalmente indica que los usuarios reciben retroalimentación rápidamente, lo que refleja un excelente rendimiento de la API. Un tiempo de respuesta alto sugiere respuestas lentas, lo que podría impactar la experiencia del usuario.
- Tasa de fallos de solicitud: De hecho, la tasa de fallos debería ser cercana a cero. Una alta tasa de fallos indica que la API no puede manejar las solicitudes correctamente en ciertas situaciones, lo que requiere un análisis y optimización de errores adicionales.
- Usuarios concurrentes: Establecer un número apropiado de usuarios concurrentes ayuda a simular la carga de usuarios del mundo real. Sin embargo, establecerlo demasiado alto puede sobrecargar el sistema, lo que lleva a la degradación del rendimiento.
Datos de API individuales:
- Solicitudes totales: Solicitudes totales enviadas para una sola API.
- Solicitudes por segundo: Número promedio de solicitudes enviadas por segundo para una sola API.
- Tiempo de respuesta promedio (ms): Tiempo de respuesta promedio para todas las solicitudes a una sola API.
- Tiempo de respuesta mínimo (ms): Tiempo de respuesta más corto entre todas las solicitudes a una sola API.
- Tiempo de respuesta máximo (ms): Tiempo de respuesta más largo entre todas las solicitudes a una sola API.
- Tiempo de respuesta del 90%: Tiempo de respuesta para el percentil 90 de las solicitudes a una sola API.
- Tasa de fallos: Porcentaje de solicitudes fallidas para una sola API.
Analizando los resultados de la prueba:
- Visualizaciones:
Diferentes colores de curva en el panel de visualización corresponden a diferentes métricas de rendimiento en el eje vertical. El eje horizontal representa la duración de la prueba de rendimiento. El eje vertical muestra métricas como la tasa de fallos de solicitud, el tiempo de respuesta promedio y las solicitudes por segundo (los usuarios concurrentes están ocultos por defecto). Puedes hacer clic en una métrica específica para resaltarla u ocultarla para un análisis enfocado.
- Filtrado y detalles:
Para examinar solicitudes fallidas específicas, haz clic en "Validate Response Error". También puedes usar la funcionalidad de filtrado para enfocarte en el rendimiento de APIs específicas.
- Informes de prueba:
Después de la prueba de rendimiento, haz clic en la pestaña "Test Reports" para ver todos los informes históricos del escenario de prueba. Estos informes detallan las "Opciones de configuración" establecidas antes de ejecutar la prueba de rendimiento.
Puedes filtrar los informes por tipo (prueba funcional, prueba de rendimiento). Al hacer clic en un informe de prueba, se te lleva a su página de detalles, mostrando las mismas métricas recopiladas durante la prueba de rendimiento.
Nota: Solo se puede ejecutar una prueba de rendimiento por proyecto a la vez. Haz clic en el botón "Terminate" en la esquina superior derecha para detener la prueba actual si se necesita ejecutar una prueba de mayor prioridad.
Conclusión
Apidog proporciona una solución fácil de usar para las pruebas de rendimiento de APIs, simplificando el proceso de establecer parámetros de prueba, ejecutar pruebas y ver resultados. Con métricas de rendimiento detalladas y un panel de visualización claro, puedes comprender de manera integral el rendimiento de tu API.
