Temps d'espera del proxy amb pnpm: comproveu la concurrència de baixada
Reduïu la pressió paral·lela innecessària sobre un proxy limitat i distingiu la concurrència de peticions dels límits de connexió per origen.
Si una petició de paquet funciona però una instal·lació produeix temps d'espera, compareu primer una quantitat menor de treball paral·lel per la mateixa ruta abans de substituir el proxy. Per a una versió de pnpm que admeti aquests paràmetres de projecte, un punt de partida diagnòstic moderat és:
networkConcurrency: 8
maxsockets: 4Utilitzeu la ubicació que admet la versió instal·lada, com ara el pnpm-workspace.yaml actual.
| Paràmetre | Recurs |
|---|---|
networkConcurrency | Treball de xarxa concurrent. |
maxsockets | Connexions per origen: protocol, amfitrió i port. |
Executeu la mateixa operació de paquets prevista i registreu errors de connexió, peticions completades i reintents. Una segona instal·lació en memòria cau no es pot comparar com a amplada de banda amb una primera baixada sense memòria cau. Una concurrència més baixa pot ajudar un intermediari limitat o simplement alentir una execució saludable; no hi ha una millora fixa sense evidència de càrrega.
Comproveu també el comportament de la versió. El pnpm actual documenta concurrència automàtica i certs ajustos relacionats amb els temps d'espera, com tractar el trànsit a través del mateix proxy com un sol amfitrió per a aquest ajust. Un paràmetre explícit fa més clar l'experiment, però no fa que cada versió planifiqui igual.
Si fins i tot una petició falla, investigueu primer el protocol, el punt final, l'autenticació, el TLS o la política d'objectiu.