Solución de problemas en pruebas de carga

Busca el mensaje o el síntoma que ves y lee por qué ocurre y qué hacer. Cada entrada enlaza con la página que tiene todos los detalles. Los mensajes se citan tal como los muestra la aplicación.

La prueba no arranca

"Failed to start test"

Qué ves: un diálogo con el título Failed to start test y el texto "Please try again. If you still encounter an error please contact us."

Por qué: LoadFocus no pudo lanzar la ejecución, y el motivo no fue ninguno de los límites de plan que se describen abajo.

Qué hacer: vuelve a iniciar la prueba. Una ejecución que LoadFocus no pudo iniciar no cuenta para las ejecuciones de tu plan (consulta la última sección de esta página). Si sigue fallando, contacta con soporte e indica el nombre de la prueba.

"Límite de ejecuciones alcanzado"

Qué ves: el diálogo de límites muestra Límite de ejecuciones alcanzado, con una línea como "Su plan incluye 30 ejecuciones de prueba en 24 horas. Su equipo ha usado 30." y la fecha en la que podrá empezar la próxima ejecución. A través de la API, el rechazo indica un motivo como number-of-daily-tests-exceeded, number-of-weekly-tests-exceeded, number-of-monthly-tests-exceeded o number-of-yearly-tests-exceeded, con los contadores current y maximum.

Por qué: tu equipo ha usado todas las ejecuciones que su plan permite en ese periodo. El límite semanal solo se aplica a las ejecuciones iniciadas a través de la API y a las programadas, en Load Free, durante una prueba gratuita y en Load Starter.

Qué hacer: espera hasta la fecha indicada o cambia a un plan con más ejecuciones. Las ejecuciones programadas que llegan a un límite se omiten, y el panel de la programación lo indica. Consulta Planes y límites y Pruebas de carga programadas.

"Su plan ha alcanzado el número de pruebas que pueden ejecutarse a la vez."

Por qué: otra prueba de tu equipo sigue en marcha y tu plan solo permite esas pruebas a la vez.

Qué hacer: espera a que termine la prueba en curso o detenla. Consulta Planes y límites.

Rechazos durante la prueba gratuita: "Ha usado las ejecuciones de su periodo de prueba", "Esta prueba necesita más usuarios virtuales", "Este sitio necesita un plan de pago"

Por qué: durante la prueba gratuita de 7 días de un plan de pago, las pruebas tienen límites reducidos: 50 usuarios virtuales, pruebas de hasta 5 minutos y 3 ejecuciones en 24 horas, sumando pruebas en la nube, JMeter y k6. Además, una prueba en la nube desde una prueba gratuita no puede apuntar a un sitio web que ya se probó desde otra prueba gratuita o una cuenta Free.

Qué hacer: el diálogo te ofrece activar tu plan ahora, lo que quita los límites de la prueba gratuita al momento, o añadir una tarjeta para tener 3 ejecuciones más hoy. Consulta Límites durante la prueba gratuita de 7 días.

"Pruebas gratuitas agotadas para este sitio web"

Por qué: todas las cuentas Free juntas tienen 3 pruebas al día y 10 al año para un mismo sitio web, y ese cupo compartido se ha agotado. Solo se aplica cuando otra cuenta ya ha probado ese sitio web en el mismo periodo.

Qué hacer: el diálogo indica cuándo puedes volver a probar el sitio gratis. Tus otros sitios web no se ven afectados, y los planes de pago no tienen cupo compartido. Consulta Límites en el plan Free.

"The test cannot run because the URL fields contain private IP addresses."

Por qué: una URL de solicitud apunta a localhost, a una dirección privada como 192.168.x.x o 10.x.x.x, o a un nombre de host que se resuelve a una de ellas. Los generadores de carga funcionan en la nube y no llegan a tu red interna.

Qué hacer: prueba una URL pública o expón el servidor local con un túnel. Consulta Qué es una URL válida para una prueba de carga y Cómo hacer pruebas de carga de un sitio web o API alojado localmente.

La prueba arranca pero falla

Una prueba k6 termina como FAILED sin resultados

Qué ves: la lista de pruebas k6 muestra FAILED y la página de resultados abre un diálogo Test run failed.

Por qué: el script falló antes de generar carga: un error de sintaxis, un import que no se puede cargar (como una extensión k6/x/...) o un setup() que lanza una excepción o agota su tiempo. Un teardown() que falla después de la prueba no hace fallar la ejecución.

Qué hacer: ejecuta el script en local con k6 run para encontrar el error, corrígelo y vuelve a subirlo. El archivo de registro de k6 está en la pestaña Registros. Consulta Análisis de resultados de tests de carga k6.

Una prueba JMeter falla o envía menos solicitudes de lo esperado

Qué ves: un diálogo Test run failed con "Please try again. There were errors reported during the test run." y un extracto del log de JMeter, o una ejecución que termina con muchas menos muestras de las previstas.

Por qué: JMeter informó de errores al ejecutar tu script, por ejemplo un plugin que falta, un grupo de hilos mal configurado o un archivo CSV que el script lee pero que no se subió.

Qué hacer: abre la pestaña Registros, lee el Archivo de registro de JMeter y busca ERROR y WARN. Consulta Análisis de archivo de log de JMeter y Análisis de logs y archivos JTL.

Los resultados parecen incorrectos

La pantalla de inicio dice que se rechazó una solicitud de prueba

Qué ves: mientras arranca una prueba en la nube, un aviso como "Cloudflare rechazó una solicitud de prueba a example.com desde AWS us-east-1. Es posible que su prueba de carga se bloquee de la misma forma."

Por qué: al iniciar una ejecución en la nube, LoadFocus envía una solicitud a la raíz del sitio desde la región de la ejecución. Una CDN o el edge del hosting que está delante del sitio la rechazó. Es una sola solicitud sin las credenciales de tu prueba, así que es una pista y no un veredicto, y la ejecución sigue.

Qué hacer: vigila la tasa de errores de la ejecución. Si después los resultados muestran el aviso de filtrado de abajo, permite el tráfico de la prueba en la configuración del firewall o de la protección contra bots de esa plataforma.

"Es probable que ... esté filtrando el tráfico de la prueba."

Qué ves: en el resumen de resultados de una prueba en la nube terminada, un aviso como "Es probable que Vercel esté filtrando el tráfico de la prueba." o "Este sitio parece estar limitando o bloqueando el tráfico de la prueba."

Por qué: al menos el 20 % de las solicitudes terminaron con 403, 429, 430 (503 en Cloudflare) o con una conexión cortada o fallida, que es lo que producen la protección contra bots, la protección DDoS y los límites de tasa. Los números describen esa protección, no tu sitio.

Qué hacer: permite el tráfico de la prueba con los rangos de IP que debes permitir, o prueba un entorno de staging con la protección relajada. Consulta Errores por tipo y tasa de errores.

"Generador de carga cerca de su capacidad - considere los tiempos de respuesta como un límite inferior"

Por qué: al menos un generador de carga llegó al 80 % de CPU o más durante la ejecución, así que los tiempos de respuesta incluyen tiempo en el que el generador esperaba a su propia CPU.

Qué hacer: reparte los usuarios entre más generadores de carga o ubicaciones, quita del script el trabajo costoso por solicitud y vuelve a ejecutar la prueba. Consulta Saturación del generador de carga.

Errores de conexión: ConnectException, HttpHostConnectException, tiempos agotados

Qué ves: filas en la pestaña Errores como HttpHostConnectException o SocketTimeoutException, o "No se pudo resolver el nombre del host (DNS)." en las explicaciones de los códigos de respuesta.

Por qué: los generadores de carga no pudieron abrir una conexión o no recibieron respuesta: el host no está disponible, el nombre no se resuelve desde internet o un firewall descarta el tráfico de los generadores.

Qué hacer: comprueba que la URL funciona desde fuera de tu red y añade los rangos de IP de LoadFocus a tu firewall o WAF. Si los errores solo empiezan a partir de cierto número de usuarios, es un límite de capacidad: compáralos con la línea de usuarios virtuales. Consulta Errores por tipo y tasa de errores.

Errores de HTTPS: SSLException, SSLHandshakeException

Qué ves: SSLException o SSLHandshakeException en la pestaña Errores, o "No se pudo establecer la conexión segura (TLS)."

Por qué: falló el handshake TLS. Las causas habituales son un certificado caducado, autofirmado o emitido por una autoridad privada, una incompatibilidad de protocolo o un servidor que corta handshakes bajo carga.

Qué hacer: revisa la cadena de certificados del host, por ejemplo con el SSL Checker gratuito. Si los errores crecen con el número de usuarios, el servidor no da abasto con los handshakes. Consulta Diferencias entre HTTP y HTTPS.

Una ejecución antigua aparece como "Caducado" y sus gráficos están vacíos

Por qué: los resultados sin procesar de más de 1 año se eliminan. La ejecución sigue en tu lista, pero sus gráficos ya no tienen datos. Las ejecuciones marcadas como línea base conservan sus resultados sin procesar.

Qué hacer: no hay nada que arreglar. Consulta Cuánto tiempo guarda LoadFocus tus datos.

Ejecuciones que no cuentan

• Una ejecución que LoadFocus no pudo iniciar no cuenta para los límites de ejecuciones de tu plan.
• Una ejecución de prueba en la nube que terminó sin enviar ni una solicitud tampoco cuenta, hasta dos de estas ejecuciones al día.
• Una ejecución que detienes tú siempre cuenta, aunque todavía no haya generado carga.

Consulta Pruebas de carga programadas para ver cómo se informa de las ejecuciones programadas omitidas.