pnpm-proxy-timeouts: kontrollera nedladdningsparallellitet
Minska onödigt parallellt tryck på en begränsad proxy och skilj förfrågningsparallellitet från anslutningsgränser per källa.
Om en enskild paketförfrågan fungerar men en installation ger timeouts, jämför en mindre mängd parallellt arbete över samma väg innan du byter ut proxyn. För en pnpm-version som stöder dessa projektinställningar är en anspråkslös diagnostisk utgångspunkt:
networkConcurrency: 8
maxsockets: 4Använd den plats som den installerade versionen stöder, till exempel aktuell pnpm-workspace.yaml. Dessa siffror är illustrativa, inte mätningar och inte en hastighetsrekommendation för din proxy.
| Inställning | Resurs |
|---|---|
networkConcurrency | Parallellt nätarbete. |
maxsockets | Anslutningar per källa: protokoll, värd och port. |
Kör samma avsedda paketoperation och registrera anslutningsfel, slutförda förfrågningar och återförsök. En cachad andra installation kan inte jämföras som bandbredd mot en första nedladdning utan cache. Lägre parallellitet kan hjälpa en begränsad mellanhand eller bara göra en frisk körning långsammare; det finns ingen fast förbättring utan belägg från arbetsbelastningen.
Kontrollera även versionsbeteendet. Aktuell pnpm dokumenterar automatisk parallellitet och vissa timeoutrelaterade justeringar, inklusive att trafik genom samma proxy behandlas som en värd för den justeringen. En explicit inställning gör experimentet tydligare men gör inte att varje version schemalägger identiskt.
Om ens en förfrågan misslyckas, undersök först protokoll, slutpunkt, autentisering, TLS eller målpolicy. Parallellitetsgränser kan inte reparera dessa fel.