Timeout proxy pnpm: verifica la concorrenza dei download
Riduci la pressione parallela non necessaria su un proxy limitato e distingui la concorrenza delle richieste dai limiti di connessione per origine.
Se una richiesta di pacchetto funziona ma un'installazione produce timeout, confronta una quantità minore di lavoro parallelo sulla stessa rotta prima di sostituire il proxy. Per una versione di pnpm che supporta queste impostazioni di progetto, un punto di partenza diagnostico misurato è:
networkConcurrency: 8
maxsockets: 4Usa la posizione supportata dalla release installata, come l'attuale pnpm-workspace.yaml. Questi numeri sono illustrativi, non misurazioni né una raccomandazione di velocità per il tuo proxy.
| Impostazione | Risorsa |
|---|---|
networkConcurrency | Lavoro di rete concorrente. |
maxsockets | Connessioni per origine: protocollo, host e porta. |
Esegui la stessa operazione sui pacchetti prevista e registra errori di connessione, richieste completate e tentativi. Una seconda installazione in cache non è confrontabile come banda con un primo download non in cache. Una concorrenza più bassa può aiutare un intermediario limitato o semplicemente rallentare un'esecuzione sana; non esiste un miglioramento fisso senza prove sul carico di lavoro.
Controlla anche il comportamento della versione. La versione attuale di pnpm documenta la concorrenza automatica e alcune correzioni legate ai timeout, incluso il trattamento del traffico attraverso lo stesso proxy come un unico host per quella correzione. Un'impostazione esplicita rende l'esperimento più chiaro ma non rende identica la pianificazione di ogni release.
Se anche una sola richiesta fallisce, indaga prima su protocollo, endpoint, autenticazione, TLS o policy di destinazione. I limiti di parallelismo non possono riparare quei guasti.