La plupart des questions de capacité arrivent à l’envers. Quelqu’un demande combien de threads faire tourner ou combien de bande passante acheter, alors qu’aucun des deux n’est connaissable tant qu’on n’a pas traduit le besoin réel, qui ressemble en général à « cinquante mille fiches produit, actualisées quotidiennement, prêtes pour 08h00 ». Cette phrase contient tout ce dont vous avez besoin. Voici comment la transformer en volume de requêtes, en concurrence, et en taille de forfait, et où se situe réellement la contrainte.
Partir des fiches, pas des requêtes
La première conversion est celle que les gens sautent, et c’est là que les estimations se trompent d’un facteur multiple.
Une fiche est rarement égale à une requête. Une fiche produit peut nécessiter une page de listing plus une page de détail, donc deux. Si le listing est paginé et que vous avez besoin de chaque élément, ajoutez les requêtes de pagination, amorties sur les fiches qu’elles produisent. Si une page de détail charge ses données depuis un second appel, c’est une requête de plus. Et si vous rendez les pages dans un navigateur plutôt que d’appeler des points de terminaison de données, une requête logique devient des dizaines de récupérations de ressources, ce qui compte énormément pour la bande passante même quand cela ne change pas le nombre logique.
Écrivez-le donc explicitement :
requests_per_record = detail_pages + (listing_pages / records_per_listing) + extra_callsPour cinquante mille fiches à, disons, 1,2 requête chacune, cela fait 60 000 requêtes par exécution. Ajoutez ensuite une marge pour les échecs, car votre taux de succès validé n’est pas de 100 %. À 90 %, il faut environ 67 000 tentatives pour obtenir 60 000 succès, et si vous relancez également les échecs transitoires, le chiffre réel est encore un peu plus élevé. Planifier sur la base des succès plutôt que des tentatives est la deuxième erreur d’estimation la plus courante.
La concurrence découle du débit et de la latence
Voici l’élément qui surprend les gens. La concurrence n’est pas un nombre que l’on choisit librement ; elle découle de la vitesse à laquelle vous devez avancer et du temps que prend chaque requête.
Si vous devez achever 67 000 requêtes dans une fenêtre de quatre heures, cela représente environ 4,7 requêtes par seconde en régime soutenu. Les requêtes résidentielles sont plus lentes que les requêtes directes, donc supposons une moyenne de deux secondes par requête de bout en bout. Le nombre de requêtes en cours nécessaire est simplement le débit multiplié par la latence :
concurrency = requests_per_second x average_latency_seconds
= 4.7 x 2
~ 10 concurrent requestsCette relation mérite d’être intégrée, car elle explique deux choses à la fois. Les cibles plus lentes ont besoin de plus de concurrence pour le même débit, ce qui explique pourquoi une cible qui se dégrade silencieusement peut affamer un planning sans qu’aucune erreur n’apparaisse. Et augmenter la concurrence n’augmente pas le débit si c’est la cible qui vous ralentit ; cela ne fait qu’accroître le nombre de requêtes en attente.
Raisonnez aussi dans l’autre sens. Si vous plafonnez la concurrence à 10 et que la latence dérive de deux secondes à cinq, votre débit chute de 5 requêtes par seconde à 2, et un travail de quatre heures en devient un de dix heures. Construire le planning avec de la marge plutôt qu’à la limite est ce qui empêche une dérive de latence de se transformer en échéance manquée.
La contrainte, c’est la cible, pas votre machine
Voici où la planification rencontre la réalité. La concurrence que votre infrastructure peut soutenir n’est presque jamais la limite contraignante. Ce qui contraint, c’est ce que la cible tolère.
Les limites de débit sont appliquées par IP et, de plus en plus, par cible en agrégat. Un pool vous permet de répartir la charge par IP, mais le total arrivant sur une même origine reste visible, donc le chiffre sur lequel planifier est ce que ce site accepte plutôt que ce que vos workers peuvent émettre. Les mécanismes de cadencement sont détaillés dans limitation de débit et throttling, et la question de répartition qui en découle, combien de dispersion votre volume nécessite, est traitée dans combien d’IP proxy avez-vous réellement besoin.
En pratique, cela signifie que votre plan doit comporter un plafond de concurrence par cible et un débit par cible, et non un réglage global unique. Cinquante cibles avec une concurrence modeste chacune constituent une proposition complètement différente du même total visant un seul site, et seule la seconde vous fait bloquer.
La bande passante est le chiffre que vous achetez réellement
Puisque les proxies résidentiels facturent au volume de données transférées, la taille du forfait découle des octets plutôt que des requêtes ou des adresses.
monthly_bandwidth = attempts_per_run x runs_per_month x average_bytes_per_responseLa variable qui domine est la dernière, et elle est entièrement sous votre contrôle. Une réponse JSON ou une page HTML légère fait quelques dizaines de kilo-octets ; une page entièrement rendue avec images, polices et scripts tiers fait plusieurs mégaoctets. À 60 000 requêtes quotidiennes, des réponses de 50 KB donnent environ 90 GB par mois, tandis que des pages rendues de 2 MB donnent environ 3,6 TB, pour la même charge de travail logique. C’est la différence entre un forfait modeste et un forfait d’entreprise, et elle est déterminée par le fait de récupérer des données ou de rendre des pages, voir quand avez-vous besoin d’un navigateur headless et réduire les coûts de bande passante.
Faites cette optimisation avant de dimensionner le forfait, car cela vous fait fréquemment descendre d’un palier. La méthode de prévision complète se trouve dans estimer la bande passante mensuelle, et les choix au niveau produit dans choisir le bon forfait.
Planification : étaler plutôt que rafaler
Deux tâches au volume quotidien identique peuvent se comporter de manière complètement différente selon le moment où elles s’exécutent.
Compresser tout dans une fenêtre d’une heure multiplie votre débit instantané contre chaque cible en même temps, ce qui est précisément la configuration qui déclenche les défenses. Étaler le même travail sur la fenêtre disponible réduit gratuitement le débit par cible, et cela laisse aussi de la place pour relancer les échecs plus tard dans l’exécution plutôt que de les voir s’accumuler à la fin.
Les exigences de fraîcheur fixent la contrainte. Si les données doivent être à jour à 08h00, vous devez les avoir collectées avant cette heure, mais c’est une échéance et non une instruction de commencer à 07h00. Là où le planning le permet, étaler sur toute la fenêtre et prioriser tôt les sources les plus volatiles est strictement préférable.
Valider avec un pilote avant de s’engager
Chaque chiffre ci-dessus est une hypothèse tant que vous n’avez pas mesuré les deux variables supposées : la latence moyenne réelle sur vos cibles effectives via des sorties résidentielles, et les octets réels par réponse une fois votre stratégie de récupération arrêtée. Les deux sont faciles à mesurer sur une petite exécution et les deux modifient sensiblement le plan.
Lancez un pilote sur environ cinq pour cent du volume prévu, enregistrez le taux de succès validé, les percentiles de latence et les octets par requête par cible, puis recalculez. Attendez-vous à ce que le résultat diffère de votre estimation dans les deux sens. La méthode de mesure est détaillée dans tester la vitesse, le taux de succès et la précision de localisation, et les versions continues de ces mêmes chiffres sont les métriques présentées dans KPI proxy.
Un résumé travaillé
Besoin : 50 000 fiches par jour, prêtes pour 08h00, fenêtre de collecte de 04h00 à 08h00.
1,2 requête par fiche, soit 60 000 succès. À 90 % de succès validé, environ 67 000 tentatives. Sur quatre heures, cela fait 4,7 par seconde. À deux secondes de latence moyenne, environ 10 requêtes simultanées en cours, que vous répartissez ensuite entre les cibles plutôt que de les pointer vers une seule. À 80 KB en moyenne par réponse, environ 5,4 GB par exécution et environ 160 GB par mois. Ajoutez de la marge à la fois sur la concurrence et sur la bande passante, car la latence dérive et les taux de succès baissent, et refaites le calcul après le pilote.
L’essentiel
Planifiez à rebours : des fiches aux requêtes, des requêtes aux tentatives après marge d’échec, des tentatives sur la fenêtre à un débit, du débit multiplié par la latence à la concurrence, et des tentatives multipliées par la taille de réponse à la bande passante. Plafonnez la concurrence et le débit par cible plutôt que globalement, car la contrainte contraignante est ce que chaque site tolère et non ce que votre infrastructure peut produire. Optimisez ce que vous récupérez avant de dimensionner le forfait, puisque rendre des pages plutôt que récupérer des données peut changer la réponse en bande passante de deux ordres de grandeur. Étalez le travail sur la fenêtre disponible plutôt que de le rafaler. Puis lancez un pilote, car la latence et les octets par réponse sont les deux hypothèses qui méritent d’être remplacées par des mesures avant de vous engager sur un forfait.
La capacité elle-même provient des proxies résidentiels, où la concurrence n’est pas la contrainte sur laquelle le forfait est dimensionné, avec une tarification au GB de sorte que le chiffre de bande passante que vous dérivez est le nombre que vous achetez réellement.