Cómo planificar el volumen de solicitudes y la concurrencia en proxies residenciales

La mayoría de las preguntas sobre capacidad se plantean al revés. Alguien pregunta cuántos hilos ejecutar o cuánto ancho de banda comprar, cuando ninguna de las dos cosas se puede saber hasta que se ha traducido el requisito real, que suele ser algo como “cincuenta mil fichas de producto, actualizadas a diario, listas para las 08:00”. Esa frase contiene todo lo necesario. A continuación se explica cómo convertirla en volumen de peticiones, concurrencia y tamaño de plan, y dónde se encuentra realmente la restricción.

Empieza por los registros, no por las peticiones

La primera conversión es la que la gente se salta, y es donde las estimaciones fallan por múltiplos.

Un registro rara vez equivale a una petición. Una ficha de producto puede necesitar una página de listado más una página de detalle, es decir, dos. Si el listado se pagina y necesitas todos los elementos, añade las peticiones de paginación, amortizadas entre los registros que producen. Si una página de detalle carga sus datos mediante una segunda llamada, esa es otra más. Y si renderizas páginas en un navegador en lugar de acceder a endpoints de datos, una petición lógica se convierte en decenas de descargas de recursos, lo cual importa enormemente para el ancho de banda aunque no cambie el recuento lógico.

Así que escríbelo de forma explícita:

requests_per_record = detail_pages + (listing_pages / records_per_listing) + extra_calls

Para cincuenta mil registros a, digamos, 1,2 peticiones cada uno, son 60.000 peticiones por ejecución. Después añade margen para fallos, porque tu tasa de éxito validada no es del 100%. Con un 90% necesitas aproximadamente 67.000 intentos para conseguir 60.000 éxitos, y si además estás reintentando fallos transitorios, la cifra real es algo más alta todavía. Planificar en función de los éxitos en lugar de los intentos es el segundo error de estimación más frecuente.

La concurrencia se deriva de la tasa y la latencia

Ahora llega la parte que sorprende a la gente. La concurrencia no es un número que elijas libremente; se deriva de lo rápido que necesitas ir y de cuánto tarda cada petición.

Si debes completar 67.000 peticiones en una ventana de cuatro horas, eso son unas 4,7 peticiones por segundo sostenidas. Las peticiones residenciales son más lentas que las directas, así que asume una media de dos segundos por petición de principio a fin. El número de peticiones en curso que necesitas es simplemente la tasa multiplicada por la latencia:

concurrency = requests_per_second x average_latency_seconds
            = 4.7 x 2
            ~ 10 concurrent requests

Vale la pena interiorizar esa relación, porque explica dos cosas a la vez. Los objetivos más lentos necesitan más concurrencia para el mismo rendimiento, razón por la cual un objetivo que se degrada silenciosamente puede desbaratar una planificación sin que aparezca ningún error. Y aumentar la concurrencia no aumenta el rendimiento si lo que te frena es el objetivo; solo incrementa el número de peticiones en espera.

Trabájalo también en el otro sentido. Si limitas la concurrencia a 10 y la latencia pasa de dos segundos a cinco, tu rendimiento cae de 5 peticiones por segundo a 2, y un trabajo de cuatro horas se convierte en uno de diez. Construir la planificación con margen en lugar de al límite es lo que evita que una deriva de latencia se convierta en un plazo incumplido.

La restricción es el objetivo, no tu máquina

Aquí es donde la planificación se topa con la realidad. La concurrencia que tu infraestructura puede sostener casi nunca es el límite vinculante. Lo que restringe es lo que el objetivo tolera.

Los límites de tasa se aplican por IP y, cada vez más, por objetivo en conjunto. Un pool te permite repartir la carga por IP, pero el total que llega a un origen sigue siendo visible, así que la cifra sobre la que hay que planificar es lo que ese sitio acepta y no lo que tus workers pueden emitir. La mecánica de ritmo está en rate limiting and throttling, y la cuestión de distribución que se deriva de ahí, cuánta dispersión necesita tu volumen, se desarrolla en how many proxy IPs you actually need.

En la práctica esto significa que tu plan debe llevar un límite de concurrencia por objetivo y una tasa por objetivo, no un único ajuste global. Cincuenta objetivos con una concurrencia modesta cada uno es una propuesta completamente distinta del mismo total dirigido a un solo sitio, y solo la segunda te acaba bloqueando.

El ancho de banda es la cifra que realmente compras

Dado que los proxies residenciales se facturan por datos transferidos, el tamaño del plan se deriva de bytes en lugar de peticiones o direcciones.

monthly_bandwidth = attempts_per_run x runs_per_month x average_bytes_per_response

La variable que domina es la última, y está totalmente bajo tu control. Una respuesta JSON o una página HTML ligera son decenas de kilobytes; una página completamente renderizada con imágenes, fuentes y scripts de terceros son varios megabytes. Con 60.000 peticiones diarias, respuestas de 50 KB suman aproximadamente 90 GB al mes, mientras que páginas renderizadas de 2 MB suman unos 3,6 TB, a partir de la misma carga de trabajo lógica. Esa es la diferencia entre un plan modesto y uno empresarial, y la decide si obtienes datos o renderizas páginas, según when you need a headless browser y cutting bandwidth costs.

Realiza esa optimización antes de dimensionar el plan, porque con frecuencia te hace bajar de nivel. El método de previsión más completo está en estimating monthly bandwidth, y las decisiones a nivel de producto en choosing the right plan.

Programación: distribuir es mejor que agrupar

Dos trabajos con el mismo volumen diario pueden comportarse de forma completamente distinta según cuándo se ejecuten.

Comprimir todo en una ventana de una hora multiplica tu tasa instantánea contra cada objetivo a la vez, que es exactamente el patrón que activa las defensas. Repartir el mismo trabajo a lo largo de la ventana disponible reduce la tasa por objetivo sin coste alguno, y además da margen para reintentar los fallos más adelante en la ejecución en lugar de acumularse al final.

Los requisitos de actualidad establecen la restricción. Si los datos deben estar vigentes a las 08:00, necesitas haberlos recopilado antes de esa hora, pero eso es un plazo límite y no una instrucción de empezar a las 07:00. Cuando la programación lo permite, repartir a lo largo de toda la ventana y priorizar antes las fuentes más volátiles es estrictamente mejor.

Valida con una prueba piloto antes de comprometerte

Cada cifra anterior es una hipótesis hasta que midas las dos variables que has asumido: la latencia media real en tus objetivos reales a través de salidas residenciales, y los bytes reales por respuesta una vez fijada tu estrategia de captura. Ambas son fáciles de medir en una ejecución pequeña y ambas modifican el plan de forma sustancial.

Ejecuta una prueba piloto con quizá un cinco por ciento del volumen previsto, registra la tasa de éxito validada, los percentiles de latencia y los bytes por petición por objetivo, y luego recalcula. Espera que el resultado difiera de tu estimación en ambas direcciones. El método de medición está en testing speed, success rate and location accuracy, y las versiones continuas de esas mismas cifras son las métricas de proxy KPIs.

Un resumen desarrollado

Requisito: 50.000 registros diarios, listos para las 08:00, ventana de recopilación de 04:00 a 08:00.

Peticiones por registro 1,2, lo que da 60.000 éxitos. Con un 90% de éxito validado, unos 67.000 intentos. En cuatro horas, eso son 4,7 por segundo. Con dos segundos de latencia media, aproximadamente 10 en curso simultáneamente, que luego repartes entre objetivos en lugar de dirigirlos a uno solo. Con 80 KB de media por respuesta, unos 5,4 GB por ejecución y aproximadamente 160 GB al mes. Añade margen tanto en la concurrencia como en el ancho de banda, porque la latencia varía y las tasas de éxito bajan, y vuelve a calcular después de la prueba piloto.

La conclusión

Planifica al revés: registros a peticiones, peticiones a intentos tras el margen por fallos, intentos entre la ventana disponible a una tasa, tasa por latencia a concurrencia, e intentos por tamaño de respuesta a ancho de banda. Limita la concurrencia y la tasa por objetivo en lugar de globalmente, porque la restricción vinculante es lo que tolera cada sitio y no lo que tu infraestructura puede producir. Optimiza lo que obtienes antes de dimensionar el plan, ya que renderizar frente a obtener datos puede cambiar la respuesta de ancho de banda en dos órdenes de magnitud. Reparte el trabajo a lo largo de la ventana disponible en lugar de agruparlo. Después ejecuta una prueba piloto, porque la latencia y los bytes por respuesta son las dos suposiciones que merece la pena sustituir por mediciones antes de comprometerte con un plan.

La capacidad en sí proviene de residential proxies, donde la concurrencia no es la restricción sobre la que se dimensiona el plan, con precios por GB para que la cifra de ancho de banda que derives sea el número que realmente estás comprando.