Antes de que una pipeline de recolección pase a producción, alguien pregunta razonablemente si aguantará a volumen completo. El instinto es hacer una prueba de carga, y el instinto es correcto, pero las pruebas de carga con proxies tienen una restricción que las pruebas de carga normales no tienen: aquello contra lo que estás enviando tráfico normalmente pertenece a otra persona.
Ese único hecho reconfigura todo el ejercicio. No estás probando si un sistema puede absorber tu carga, estás caracterizando el comportamiento de tu propia pipeline y encontrando tu techo, sin llevar a cabo una prueba de estrés no anunciada contra un tercero. Así es como hacerlo correctamente.
Qué estás probando en realidad
Separa las cuatro preguntas, porque necesitan pruebas distintas y solo una de ellas implica un objetivo real.
La capacidad de tu propia pipeline. Cuántas solicitudes concurrentes pueden soportar tus workers, la gestión de conexiones, el parsing y el almacenamiento antes de que algo se sature. Esto es una prueba de tu código y tu infraestructura y se puede ejecutar sin tocar el sitio de nadie más.
El comportamiento de la ruta del proxy bajo concurrencia. Cómo se mueven la latencia y la tasa de éxito a medida que aumentas las solicitudes en vuelo a través del gateway. También es, en su mayor parte, independiente de cualquier objetivo concreto.
La tolerancia del objetivo. Qué ritmo acepta un sitio concreto antes de limitarte o desafiarte. Esta es la que hay que abordar con cuidado y de forma incremental, no con un generador de carga.
El rendimiento de extremo a extremo. Lo que producen todos los puntos anteriores juntos, que es el número del que realmente depende tu calendario.
Confundirlas produce el clásico mal resultado: una “prueba de carga” que golpea un objetivo, se bloquea, y no te dice nada salvo que te pueden bloquear.
Prueba primero contra algo que sea tuyo
Levanta un objetivo que controles y que devuelva una respuesta de tamaño realista, y apunta la pipeline hacia él a través de los proxies. Esto aísla todo excepto al tercero.
Aquí aprendes sorprendentemente mucho. Si tu pool de workers realmente alcanza la concurrencia que configuraste. Si la gestión de conexiones hace lo que crees, ya que las conexiones agrupadas se comportan de forma distinta a través de un gateway, según IP not rotating. Dónde se convierte tu parsing o almacenamiento en el cuello de botella. Y qué distribución de latencia añade la ruta del proxy, sin la variabilidad propia de un objetivo mezclada.
Usa tamaños de payload realistas. Una prueba contra un endpoint diminuto sobreestimará tu rendimiento gravemente, porque tanto el ancho de banda como el parsing escalan con el tamaño de la respuesta y la latencia residencial domina de forma distinta según el tamaño del payload.
Mide las cosas correctas
El rendimiento por sí solo es un mal resumen. Cinco mediciones hacen que una prueba de carga sea interpretable.
Tasa de éxito validada, no éxito HTTP. Una prueba que informa un 100% de éxito mientras devuelve páginas de desafío está midiendo lo equivocado, según detecting blocked or fake content.
Percentiles de latencia, concretamente p50, p95 y p99. La latencia residencial tiene una distribución amplia, así que un promedio oculta la cola que en realidad determina si un trabajo con plazo fijo termina.
Rendimiento en función de la concurrencia, representado gráficamente en lugar de muestreado en un solo punto. La característica interesante es dónde se aplana la curva, ya que más allá de ese punto estás añadiendo solicitudes en vuelo sin añadir finalizaciones.
Distribución de clases de error, porque la mezcla te dice qué te está limitando. Los timeouts apuntan en una dirección, las señales de límite de tasa en otra, y los desafíos en otra distinta, según common residential proxy errors.
Bytes por solicitud, ya que determina el coste a volumen de producción y es fácil de medir ahora y caro de descubrir más tarde, según estimating monthly bandwidth.
Aumenta gradualmente, no de golpe
Aumenta la concurrencia en pasos, mantén cada paso el tiempo suficiente para que las cifras se estabilicen, y registra el conjunto completo de mediciones en cada nivel. Una prueba de pico apenas te dice algo útil aquí, porque el fallo que produce es indistinguible de un objetivo reaccionando a una ráfaga.
La forma que estás buscando es aquella en la que el rendimiento deja de subir con la concurrencia, y donde la latencia p95 empieza a subir bruscamente. Esas dos cosas suelen coincidir y marcan tu techo práctico. Ejecuta tu trabajo de producción en algún punto por debajo de él, en lugar de justo en él, porque el techo se mueve con el comportamiento del objetivo, la hora del día y las condiciones del pool.
for concurrency in [5, 10, 20, 40, 80]: stats = run_step(concurrency, duration_seconds=180) # hold, then record print(concurrency, stats.validated_success, stats.p50, stats.p95, stats.rps, stats.bytes_per_req, stats.error_mix) if stats.validated_success < 0.9 or stats.p95 > LATENCY_BUDGET: break # found the kneeCalibrar contra un objetivo real, con cuidado
Con el tiempo necesitas saber qué toleran realmente tus fuentes, y eso no se puede aprender de una simulación. Hazlo como calibración, no como prueba de carga.
Empieza bien por debajo de tu ritmo previsto y aumenta despacio, vigilando la tasa de éxito validada en lugar de los códigos de estado. Deja de aumentar ante la primera señal de degradación en lugar de forzar hasta el fallo, ya que el objetivo es encontrar un ritmo sostenible, no un punto de ruptura. Extiende la calibración durante un periodo más largo de lo que parece necesario, porque la limitación a menudo se aplica sobre ventanas móviles y una ráfaga corta puede pasar mientras que un ritmo sostenido no.
Respeta lo que el objetivo te indica. Un 429 o un Retry-After es una instrucción directa y la respuesta correcta es reducir el ritmo en lugar de rotar direcciones para poder mantenerlo, que es la distinción en rate limiting and throttling.
Y mantenlo proporcionado: tu tráfico de calibración debería ser un error de redondeo frente a la carga normal del sitio. Someter deliberadamente a estrés la infraestructura de un tercero no es un ejercicio de ingeniería inofensivo, y según la escala y la intención puede llegar a constituir una interferencia. Si necesitas conocer con precisión los límites de un partner, pregúntaselo.
Interpretar los resultados
Traduce la curva en los dos números que necesita tu configuración de producción: un límite de concurrencia por objetivo y un ritmo por objetivo, ambos fijados por debajo del codo con margen.
Luego, contrástalo con tu calendario. La concurrencia se deriva del ritmo y la latencia, así que si tu latencia p50 medida es más alta de lo que suponías, la concurrencia que necesitas para un plazo determinado aumenta en consecuencia, que es la aritmética en planning request volume and concurrency.
Por último, trata los resultados como perecederos. Las defensas del objetivo cambian, las condiciones del pool varían según la hora y el mercado, y un número medido en una semana tranquila no se sostendrá durante un pico. Repite la calibración periódicamente y, más importante, ejecuta las mismas mediciones de forma continua en producción para que el techo se observe en lugar de suponerse, según monitoring proxy health at scale.
La conclusión
Las pruebas de carga con proxies son caracterización de capacidad, no un asalto a un tercero. Separa las cuatro preguntas y prueba las dos primeras contra infraestructura propia con tamaños de payload realistas, lo cual aísla los cuellos de botella reales de tu pipeline de la variabilidad de un objetivo. Mide la tasa de éxito validada, los percentiles de latencia, el rendimiento frente a la concurrencia, la mezcla de clases de error y los bytes por solicitud, luego aumenta en pasos y busca el codo donde el rendimiento se aplana y el p95 sube. Calibra contra objetivos reales despacio y detente ante la primera degradación en lugar de forzar hasta el fallo, respetando las señales de límite de tasa reduciendo el ritmo en lugar de rotar. Fija los límites de producción por debajo del codo, vuelve a derivar tu concurrencia a partir de la latencia medida, y sigue midiendo en producción porque el techo se mueve.
La ruta que se está probando son los residential proxies, donde la concurrencia y la geografía son parámetros por solicitud en lugar de ajustes de plan, facturados por GB de modo que una prueba de carga bien delimitada cuesta aproximadamente lo que cuesta su ancho de banda.