Quieres saber qué le pasa a tu API cuando 80 personas acceden a la compra al mismo tiempo. Así que abres Locust, y lo primero que te pide es que escribas una clase de Python. Define un HttpUser. Decora los métodos con @task. Construye un locustfile.py, configura un entorno virtual, fija algunas dependencias y luego averigua por qué tu token de autenticación no se reutiliza en las solicitudes. Nada de eso es la prueba. Es el costo de admisión antes de que comience la prueba.
Locust es una buena herramienta, y ese diseño de código primero es su razón de ser. Pero si tu objetivo es una respuesta directa a "¿mi endpoint de inicio de sesión soporta 100 usuarios concurrentes?", escribir y mantener un arnés de Python es mucho trabajo para obtener un solo número. Hay un camino más rápido cuando las solicitudes de API que quieres bombardear ya residen en un cliente de API. Con Apidog, apuntas una prueba de rendimiento a un escenario de prueba existente, estableces el número de usuarios virtuales y una duración, y lees el rendimiento, el tiempo de respuesta y la tasa de error en un gráfico en vivo. Sin locustfile, sin pip install, sin Python en absoluto.
Lo que Locust realmente hace bien
Locust es una herramienta de prueba de carga de código abierto escrita en Python, y es buena para lo que fue diseñada. Describes el comportamiento del usuario como código. Un usuario virtual es una clase de Python, y las cosas que hace ese usuario son métodos que etiquetas como tareas. Aquí está la forma canónica de un locustfile.py:
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
Lo ejecutas con locust -f locustfile.py, abres la interfaz web en localhost:8089, estableces un número de usuarios y una tasa de aparición, y observas cómo aumentan los números. Debido a que el comportamiento es código, obtienes un poder expresivo real. Lógica condicional, distribuciones de tareas ponderadas, viajes de usuario secuenciales, clientes personalizados para protocolos más allá de HTTP, estado compartido entre solicitudes. La ponderación @task(3) frente a @task(1) anterior significa que la navegación ocurre tres veces más a menudo que añadir al carrito, lo cual es el tipo de realismo que una lista plana de solicitudes no puede capturar.
Locust también escala horizontalmente. Lo ejecutas distribuido en múltiples procesos de trabajo o máquinas y un único maestro los coordina, para que puedas superar lo que una sola máquina puede generar. Es impulsado por eventos en su base, por lo que cada trabajador maneja miles de usuarios concurrentes sin que un hilo por usuario consuma memoria. Para un equipo que ya trabaja en Python, trata sus pruebas de carga como código con control de versiones y necesita modelar un comportamiento de usuario complejo de múltiples pasos, Locust es una opción sólida. Nada de eso está en disputa.
El costo es el código. Cada prueba es un programa que escribes, depuras y mantienes. Si tu API cambia, el locustfile cambia. Si un nuevo ingeniero necesita ejecutar la prueba, necesita un entorno de Python que coincida. Y si no escribes Python, el lenguaje en sí se convierte en un requisito previo para responder a una pregunta que no tiene nada que ver con Python.
Dónde el modelo de "código primero" se convierte en fricción
La fricción aparece en tres lugares.
Primero, la configuración. Antes de medir cualquier cosa, instalas Python, creas un entorno virtual, pip install locust, y escribes el arnés. Para una verificación rápida de "puede este endpoint soportar 50 usuarios", eso es más infraestructura que carga útil.
Segundo, la duplicación. Probablemente ya tengas estas solicitudes definidas en algún lugar. Quizás en Postman, quizás en un archivo .http, quizás en un cliente de API que tu equipo usa todos los días. El locustfile vuelve a describir solicitudes que ya existen, incluyendo el flujo de autenticación, los encabezados, los cuerpos de las solicitudes. Ahora mantienes dos copias del mismo conocimiento de la API, y se desincronizan.
Tercero, las personas que necesitan la respuesta. Un ingeniero de QA, un gerente de producto preocupado por un lanzamiento, o un desarrollador frontend que solo quiere saber si la API sobrevive al correo electrónico de marketing, todos necesitan el resultado de la prueba de carga. No necesariamente necesitan leer o escribir Python para merecerlo. Cuando la prueba está bloqueada detrás de un locustfile, la respuesta está bloqueada detrás de un conjunto de habilidades.
Si tus pruebas de carga realmente necesitan lógica de bifurcación y clientes de protocolo personalizados, esa fricción vale la pena y Locust es la herramienta adecuada. Para el caso común de "ejecutar mis solicitudes de API reales bajo carga concurrente y mostrarme los números", vale la pena preguntar si la capa de Python te está aportando algo.
El enfoque de Apidog: prueba de carga las solicitudes que ya tienes
Apidog aborda las pruebas de carga desde la otra dirección. No escribes un script que describa las solicitudes. Tomas las solicitudes que ya has construido y las ejecutas bajo carga. La unidad de una prueba de carga es un escenario de prueba, que es simplemente un conjunto ordenado de solicitudes de API con sus entornos, variables y aserciones ya adjuntos. Si has usado Apidog para probar o depurar un endpoint, la solicitud ya está ahí. La prueba de rendimiento la reutiliza.
Aquí está el flujo completo.
- Abre el escenario de prueba que deseas someter a prueba de carga. Este es el mismo escenario que ejecutarías como una prueba funcional normal, con las mismas solicitudes y las mismas variables de entorno.
- Elige ejecutarlo como una prueba de rendimiento en lugar de una sola pasada.
- Establece el número de usuarios virtuales. Apidog soporta hasta 100 usuarios virtuales, cada uno de ellos realizando un bucle a través de cada solicitud en el escenario en paralelo durante toda la prueba.
- Establece la duración de la prueba. Es el tiempo que los usuarios virtuales continúan en el bucle.
- Establece una duración de rampa si quieres un ascenso gradual. Durante los primeros X minutos, Apidog pone a los usuarios en línea de forma incremental en lugar de todos a la vez; si lo pones a 0, cada usuario virtual comienza inmediatamente.
- Si tu escenario se basa en datos, elige un modo de coincidencia. "Coincidencia aleatoria" hace que cada usuario virtual extraiga una fila aleatoria de tus datos de prueba en cada bucle; "Coincidencia secuencial" recorre las filas en orden.
- Inicia la prueba y observa el panel en vivo.
El gráfico se actualiza en tiempo real. Para cada API en el escenario, obtienes el Total de Solicitudes, el Rendimiento Promedio, el Tiempo de Respuesta Promedio, el Tiempo de Respuesta Máximo y Mínimo, y los Errores. Pasa el cursor sobre el gráfico para ver los números de un segmento de tiempo determinado. Una pestaña de "Error" desglosa las solicitudes fallidas para que puedas ver qué endpoint comenzó a fallar y cuándo. Cuando la ejecución termina, la pestaña "Informes de prueba" mantiene el historial para que puedas comparar la ejecución de hoy con la de la semana pasada después de implementar un cambio.
El objetivo principal es que no hay un locustfile que escribir ni un entorno Python que gestionar. La misma solicitud que pasó tu prueba funcional es la solicitud que genera carga. Esa es la diferencia entre describir una prueba de carga y ejecutarla. Apidog es una plataforma de API todo en uno, por lo que el diseño, la depuración, las pruebas funcionales y las pruebas de carga de un endpoint se realizan con una única definición de ese endpoint.
Una comparación concreta
Digamos que quieres confirmar que un endpoint de inicio de sesión maneja 100 usuarios concurrentes durante dos minutos, con una rampa de 30 segundos.
En Locust, escribes una clase de usuario con una tarea que publica credenciales, maneja el token que devuelve la respuesta, lo almacena para cualquier llamada de seguimiento, guarda el archivo, inicias locust -f login_test.py, abres la interfaz web e ingresas 100 usuarios, una tasa de aparición y un tiempo de ejecución. Si el manejo del token es incorrecto, depuras Python antes de depurar tu API.
En Apidog, abres el escenario de prueba de inicio de sesión que ya construiste, lo cambias a una prueba de rendimiento, escribes 100 para usuarios virtuales, 2 minutos para la duración, 30 segundos para la rampa, y lo inicias. La autenticación que ya funcionó en tu prueba funcional sigue funcionando, porque es el mismo escenario. Lees la curva de tiempo de respuesta y la tasa de error a medida que ocurren.
Ambos llegan al mismo tipo de respuesta. Uno te pide que escribas y mantengas un programa primero. El otro reutiliza lo que ya tienes. Para viajes de usuario complejos y modelados por código, el programa vale la pena. Para "¿mi endpoint es rápido y estable bajo carga?", la reutilización gana en tiempo.
Límites honestos en ambos lados
Sé claro sobre las compensaciones, porque elegir la herramienta equivocada te hará perder un día de cualquier manera.
Las pruebas de rendimiento de Apidog alcanzan un máximo de 100 usuarios virtuales desde una sola ejecución, y la carga se genera desde tu máquina ejecutando la aplicación. Si necesitas simular decenas de miles de usuarios o generar carga desde múltiples regiones geográficas a la vez, eso va más allá de lo que las pruebas de rendimiento de la aplicación pueden cubrir, y una configuración distribuida como los trabajadores de Locust o un clúster dedicado de generación de carga es la opción correcta. Apidog también registra las solicitudes fallidas estadísticamente en lugar de capturar el cuerpo completo de la solicitud y la respuesta para cada fallo, por lo que la depuración forense profunda de una llamada fallida específica a mitad de la carga no es su punto fuerte.
La compensación de Locust es de lo que trata todo este artículo. El poder proviene del código, y el código es un costo permanente. Mantienes un locustfile por escenario, mantienes un entorno de Python y aceptas que cualquiera que quiera ejecutar la prueba necesita leer Python para entenderla. Para un número muy alto de usuarios virtuales y una lógica de protocolo a medida, ese costo te aporta algo real. Para la verificación diaria de la carga de la API, es una sobrecarga.
Una regla razonable: si puedes describir la prueba como "ejecutar estas solicitudes a esta concurrencia durante este tiempo", opta por la prueba de rendimiento en la aplicación. Si necesitas ramificación condicional, gráficos de tareas ponderados, clientes personalizados o un número de usuarios de seis cifras, opta por el código. Para una visión más amplia de dónde encaja cada opción, consulta nuestro resumen de las mejores herramientas de prueba de carga y la comparación de herramientas de prueba de carga específicas para API.
Interpretando los números que obtienes
Una prueba de carga solo es útil si sabes lo que significa la salida. Cuatro métricas son las más importantes.
La productividad (RPS/TPS) es el número de solicitudes o transacciones por segundo, la tasa que tu API realmente atendió. Es el límite de lo que tu sistema puede manejar. Si la productividad se estanca mientras sigues añadiendo usuarios virtuales, has encontrado un punto de saturación.
El tiempo de respuesta (latencia) es el tiempo que tardó cada solicitud. Observa el promedio, pero observa el máximo con más atención. Un promedio saludable con un máximo feo significa que algunos usuarios están teniendo una mala experiencia, incluso si la mayoría están bien. La latencia en el extremo es donde los usuarios reales sienten el dolor.
La tasa de error es la proporción de solicitudes que fallaron. Una prueba limpia con poca carga que comienza a arrojar errores 500 o tiempos de espera a medida que aumentan los usuarios virtuales te dice exactamente dónde se rompe el sistema. El punto donde comienzan los errores suele ser más interesante que el número bruto de rendimiento.
La concurrencia es la cantidad de usuarios virtuales activos. En Apidog, esta es la cantidad de usuarios virtuales que estableces, y la rampa controla la velocidad a la que se alcanza. La rampa importa porque un sistema que maneja 100 usuarios alcanzados gradualmente aún puede caerse si los 100 llegan en el mismo segundo.
Si quieres una versión más profunda de esto, nuestra guía sobre pruebas de rendimiento de API analiza las métricas, los tipos de prueba y cómo leer las curvas, y el artículo sobre fundamentos de las pruebas de rendimiento cubre la disciplina más ampliamente.
Cómo esto encaja con las herramientas con las que ya comparas
Si has usado JMeter, el modelo mental es similar al de Apidog, ya que ambos te permiten configurar una prueba de carga a través de una interfaz de usuario en lugar de código. JMeter lo compensa con un plan de prueba más pesado basado en XML y una curva de aprendizaje más pronunciada; nuestro tutorial de pruebas de carga con JMeter lo cubre en detalle. Si has ejecutado carga a través del "collection runner" de Postman, habrás visto una versión más ligera de la misma idea, cubierta en pruebas de carga con Postman, y Apidog añade informes de rendimiento dedicados además de solicitudes que también puedes usar para pruebas de API sin Postman. Apidog se sitúa entre la simplicidad sin código que la gente desea y la reutilización de solicitudes que te evita mantener un arnés separado.
El hilo conductor de todos ellos es que tu prueba de carga debe reutilizar el conocimiento de la API que ya codificaste, no duplicarlo en un nuevo lenguaje. Locust lo duplica en Python porque Python es su fortaleza. Apidog reutiliza tus escenarios porque la reutilización es su fortaleza.
Primeros pasos
Si tus solicitudes ya están en Apidog, puedes ejecutar una prueba de rendimiento en los próximos cinco minutos. Abre un escenario de prueba, cámbialo a una prueba de rendimiento, configura los usuarios virtuales y la duración, y ejecútalo. Si vienes de un locustfile y estás cansado de mantener la capa de Python, reconstruye el escenario una vez en la aplicación y no volverás a escribir código de prueba de carga para ese endpoint.
Descarga Apidog y apunta una prueba de rendimiento a un endpoint que ya pruebas. Tendrás curvas de rendimiento, latencia y tasa de error antes de que hubieras terminado de escribir el locustfile equivalente. Locust sigue siendo la respuesta correcta para cargas distribuidas y modeladas por código a una escala masiva. Para la pregunta que la mayoría de los desarrolladores realmente se hacen, ejecuta las solicitudes que ya tienes.
Preguntas Frecuentes
¿Apidog es un reemplazo directo de Locust?
No para todos los trabajos. Para las pruebas de carga de solicitudes de API de hasta 100 usuarios virtuales sin escribir código, Apidog reemplaza todo el flujo de trabajo de Locust porque ejecuta directamente tus escenarios de prueba existentes. Para cargas distribuidas con un número muy alto de usuarios o protocolos personalizados no HTTP modelados en código, Locust sigue siendo la mejor opción.
¿Necesito escribir algún código para hacer pruebas de carga en Apidog?
No. Configuras los usuarios virtuales, la duración de la prueba y el tiempo de arranque en la interfaz de usuario, y la prueba ejecuta las solicitudes de un escenario de prueba que ya has creado. No hay un locustfile ni un entorno de Python que configurar.
¿Cuántos usuarios virtuales puede simular Apidog?
Hasta 100 usuarios virtuales en una única prueba de rendimiento. Cada uno de ellos recorre todas las API del escenario en paralelo durante la duración que establezcas. Si necesitas muchos más o carga desde múltiples regiones, una herramienta distribuida basada en código como Locust es la opción correcta.
¿Qué métricas informa la prueba de rendimiento de Apidog?
Para cada API en el escenario, obtienes el Total de Solicitudes, el Rendimiento Promedio, el Tiempo de Respuesta Promedio, el Tiempo de Respuesta Máximo y Mínimo, y los Errores, actualizados en vivo en un gráfico. Una pestaña de Errores desglosa las solicitudes fallidas, y la pestaña de Informes de Prueba guarda el historial de ejecución para que puedas comparar los cambios.
¿Puedo hacer pruebas de carga con solicitudes basadas en datos?
Sí. Si tu escenario está respaldado por datos de prueba, elige "Coincidencia aleatoria" para que cada usuario virtual extraiga una fila aleatoria en cada bucle, o "Coincidencia secuencial" para recorrer las filas en orden.
¿Debería seguir usando Locust para algo?
Sí, cuando sus puntos fuertes coinciden con tu necesidad: comportamiento de usuario definido por código con ramificación y tareas ponderadas, clientes de protocolo personalizados y generación de carga distribuida que supera con creces los 100 usuarios virtuales. Usa la herramienta adecuada para la forma de la prueba.