Donnez à chaque proxy aiohttp son propre budget de concurrence

Un pool de proxys peut contenir des points de terminaison aux capacités très différentes. Autoriser cinquante opérations dans l'application n'empêche pas quarante-neuf d'entre elles de choisir le même proxy.

Si la règle est « au plus quatre opérations en cours via chaque proxy sélectionné », exprimez cette règle directement. Gardez un sémaphore par identité de proxy et acquérez-le autour du travail qui consomme la capacité du proxy.

limits = {proxy: asyncio.Semaphore(4) for proxy in proxy_urls}

async def fetch(session, proxy, url):
    async with limits[proxy]:
        async with session.get(url, proxy=proxy) as response:
            return await response.read()

Cet exemple suppose que asyncio a été importé et que les URL des proxys ont été validées. Pour les requêtes publiques sur une route de proxy public autorisée, la liste de proxys HTTP fournit des candidats pour les URL de proxy d'aiohttp. Une vraie application devrait aussi définir son propre délai d'expiration de requête et décider de la quantité de données de réponse dont elle a besoin. Lire un gros fichier entièrement en mémoire est une décision de ressources distincte.

Gardez le permis pour la partie coûteuse

Libérer le sémaphore dès l'arrivée des en-têtes de réponse peut annuler la limite voulue. Un corps en streaming peut continuer d'utiliser la connexion longtemps après. Gardez le permis jusqu'à ce que le corps soit consommé ou que la réponse soit fermée selon le flux de travail de l'application.

Les gestionnaires de contexte imbriqués rendent le nettoyage visible lorsqu'une exception ou une annulation quitte l'opération. Évitez d'acquérir manuellement et de libérer seulement en bas d'une fonction réussie.

Les limites de connexion répondent à une autre question

Les limites du connecteur d'aiohttp plafonnent les connexions selon les règles documentées du connecteur. Elles restent utiles à côté d'un sémaphore d'application. Une limite de connexions par destination n'exprime pas, par son seul nom, un budget partagé par toutes les destinations affectées à un proxy.

Distinguez aussi la concurrence du débit de requêtes. Quatre requêtes de longue durée et quatre requêtes très courtes utilisent la même allocation de concurrence tout en produisant des débits de requêtes par seconde différents. Un service doté d'une politique de débit peut nécessiter un cadencement ou un limiteur de débit distinct.

Choisissez un identifiant de proxy stable et non secret pour les journaux et les métriques. Si deux URL porteuses d'identifiants renvoient au même pool de capacité, décidez si elles doivent partager un budget. Inversement, des ports ou des comptes différents peuvent représenter des limites distinctes lorsque l'opérateur les documente ainsi.

Lorsque le débit chute, examinez où le travail attend : votre sémaphore, le connecteur, l'établissement de la connexion au proxy ou la lecture des réponses. Relever toutes les limites à la fois rend cette distinction plus difficile et peut déplacer la file vers un proxy que vous ne contrôlez pas.