Cómo hacer pruebas de carga de un sitio web o API alojado localmente
Por qué necesitas una URL pública
Nuestros generadores de carga están alojados en la nube, así que tu servicio, sitio web, API o servicio web necesita estar disponible públicamente para que nuestros agentes de pruebas de carga puedan llegar a tu endpoint.
Si alojas tu servicio, sitio web, API o servicio web localmente, hay algunas herramientas que puedes usar para exponer un sitio web alojado localmente a Internet.
Los generadores de carga se ejecutan en centros de datos en la nube, no en tu máquina, así que nunca podrán resolver http://localhost, un rango de IP privado como 192.168.x.x o 10.x.x.x, ni un puerto que solo esté abierto en tu portátil. Consulta https://loadfocus.com/docs/es-es/knowledge-base/using-valid-url-endpoints para la lista completa de qué cuenta como un destino alcanzable.
Herramientas que exponen un servidor local a Internet
Aquí tienes servicios que te permiten exponer ciertos puertos de tu máquina local para que el mundo exterior pueda conectarse a ellos:
Los servicios anteriores te permiten compartir fácilmente un servicio web en tu máquina de desarrollo local sin tener que tocar la configuración de DNS y firewall.
Cómo funcionan las herramientas de túnel
Ambas herramientas siguen el mismo patrón básico: un pequeño cliente en tu máquina abre una conexión saliente hacia el servidor de retransmisión (relay) del proveedor del túnel (las conexiones salientes rara vez son bloqueadas por firewalls o NAT). El proveedor asigna una URL pública y reenvía las solicitudes entrantes a esa URL de vuelta por el túnel hasta el puerto que expusiste localmente. No hace falta cambiar el DNS, redirigir puertos ni tocar reglas de firewall, por eso es la forma más rápida de hacer que una app local sea accesible para una prueba rápida.
Qué considerar antes de hacer pruebas de carga a través de un túnel
- Límites del plan gratuito: la mayoría de los planes de túnel gratuitos limitan el ancho de banda o el número de conexiones concurrentes. Bajo carga real, con cientos o miles de usuarios virtuales, puedes alcanzar el límite propio del túnel antes de alcanzar el de tu aplicación, y las cifras que obtengas describirán el túnel, no tu app.
- Latencia adicional: cada solicitud hace ahora un salto adicional a través del servidor de retransmisión del proveedor del túnel. Los tiempos de respuesta serán más altos que los que mostraría el mismo código una vez desplegado detrás de tu infraestructura habitual, así que trata las cifras absolutas con cautela.
- Estabilidad durante la prueba: si el proceso del túnel falla, o la máquina que lo ejecuta se suspende o pierde la conexión de red, todas las solicitudes en curso fallan a la vez. Para cualquier cosa más larga que una prueba de humo rápida, ejecuta el túnel desde una máquina siempre encendida en lugar de un portátil.
- Exposición: un túnel hace que tu entorno local sea accesible para cualquiera que tenga, o adivine, la URL generada, mientras el túnel permanezca abierto. Mantén la ventana de exposición corta, usa las opciones de autenticación del proveedor si están disponibles, y evita usar un túnel en un entorno que contenga datos reales de producción.
Cuándo un túnel es la herramienta adecuada
Un túnel es una buena opción para una comprobación rápida: confirmar que un endpoint soporta un número modesto de solicitudes concurrentes antes de publicarlo, o reproducir un problema encontrado en una prueba en la nube contra una build local. Para una planificación de capacidad seria o cifras de referencia, despliega en un entorno de staging que se parezca lo más posible a la infraestructura de producción. El salto del túnel añade ruido que hace que los tiempos de respuesta absolutos no sean fiables, aunque las comparaciones relativas, probar la misma configuración con túnel antes y después de un cambio de código, todavía pueden decirte algo útil.