Délais d'expiration du proxy pnpm : vérifier la concurrence des téléchargements
Réduisez la pression parallèle inutile sur un proxy limité et distinguez la concurrence des requêtes des limites de connexion par origine.
Si une requête de paquet fonctionne mais qu'une installation produit des délais d'expiration, comparez une moindre quantité de travail parallèle sur la même route avant de remplacer le proxy. Pour une version de pnpm prenant en charge ces réglages de projet, un point de départ de diagnostic modeste est :
networkConcurrency: 8
maxsockets: 4Utilisez l'emplacement pris en charge par la version installée, par exemple le pnpm-workspace.yaml actuel. Ces nombres sont illustratifs, et non des mesures ni une recommandation de vitesse pour votre proxy.
| Réglage | Ressource |
|---|---|
networkConcurrency | Travail réseau concurrent. |
maxsockets | Connexions par origine : protocole, hôte et port. |
Exécutez la même opération de paquet prévue et enregistrez les erreurs de connexion, les requêtes terminées et les nouvelles tentatives. Une seconde installation mise en cache ne peut pas être comparée en bande passante à un premier téléchargement non mis en cache. Une concurrence plus faible peut aider un intermédiaire contraint ou simplement ralentir une exécution saine ; il n'existe pas d'amélioration fixe sans preuve de charge de travail.
Vérifiez aussi le comportement selon la version. pnpm actuel documente une concurrence automatique et certains ajustements liés aux délais d'expiration, notamment le fait de traiter le trafic passant par le même proxy comme un seul hôte pour cet ajustement. Un réglage explicite rend l'expérience plus claire, mais ne fait pas planifier chaque version de la même manière.
Si même une seule requête échoue, vérifiez d'abord le protocole, le point de terminaison, l'authentification, TLS ou la politique de la cible. Les limites de parallélisme ne peuvent pas réparer ces échecs.