Tiempos de espera del proxy de pnpm: comprobar la concurrencia de descargas
Reduzca la presión paralela innecesaria sobre un proxy limitado y distinga la concurrencia de solicitudes de los límites de conexión por origen.
Si una solicitud de paquete funciona pero una instalación produce tiempos de espera, compare una cantidad menor de trabajo en paralelo por la misma ruta antes de sustituir el proxy. Para una versión de pnpm que admita estos ajustes de proyecto, un punto de partida diagnóstico moderado es:
networkConcurrency: 8
maxsockets: 4Utilice la ubicación admitida por la versión instalada, como el actual pnpm-workspace.yaml. Estas cifras son ilustrativas, no mediciones ni una recomendación de velocidad para su proxy.
| Ajuste | Recurso |
|---|---|
networkConcurrency | Trabajo de red concurrente. |
maxsockets | Conexiones por origen: protocolo, host y puerto. |
Ejecute la misma operación de paquetes prevista y registre errores de conexión, solicitudes completadas y reintentos. Una segunda instalación en caché no se puede comparar como ancho de banda con una primera descarga sin caché. Una concurrencia menor puede ayudar a un intermediario limitado o simplemente ralentizar una ejecución sana; no hay una mejora fija sin evidencia de la carga de trabajo.
Compruebe también el comportamiento de la versión. El pnpm actual documenta concurrencia automática y ciertos ajustes relacionados con tiempos de espera, incluido tratar el tráfico a través del mismo proxy como un solo host para ese ajuste. Un ajuste explícito hace más claro el experimento, pero no hace que todas las versiones programen de forma idéntica.
Si incluso una sola solicitud falla, investigue primero el protocolo, el punto de conexión, la autenticación, TLS o la política de destino. Los límites de paralelismo no pueden reparar esos fallos.