Тайм-ауты прокси в pnpm: проверьте параллелизм загрузки
Снизьте лишнюю параллельную нагрузку на ограниченный прокси и отличайте параллелизм запросов от лимитов соединений на каждый источник.
Если один запрос пакета работает, а установка выдаёт тайм-ауты, сравните меньший объём параллельной работы по тому же маршруту, прежде чем заменять прокси. Для версии pnpm, поддерживающей эти настройки проекта, скромная диагностическая отправная точка:
networkConcurrency: 8
maxsockets: 4Используйте расположение, поддерживаемое установленным релизом, например текущий pnpm-workspace.yaml. Эти числа приведены для примера: это не измерения и не рекомендация по скорости для вашего прокси.
| Настройка | Ресурс |
|---|---|
networkConcurrency | Параллельная сетевая работа. |
maxsockets | Соединения на источник: протокол, хост и порт. |
Выполните ту же намеченную операцию с пакетом и зафиксируйте ошибки подключения, завершённые запросы и повторы. Кэшированную вторую установку нельзя сравнивать по пропускной способности с первой загрузкой без кэша. Снижение параллелизма может помочь ограниченному посреднику или всего лишь замедлить исправный прогон; без данных о нагрузке нет фиксированного улучшения.
Проверьте и поведение версии. Текущий pnpm документирует автоматический параллелизм и некоторые корректировки, связанные с тайм-аутами, включая рассмотрение трафика через один и тот же прокси как одного хоста для такой корректировки. Явная настройка делает эксперимент понятнее, но не заставляет каждый релиз планировать одинаково.
Если не проходит хотя бы один запрос, сначала исследуйте протокол, конечную точку, аутентификацию, TLS или целевую политику. Ограничения параллелизма не устранят такие сбои.