Тайм-аўты проксі pnpm: праверце паралельнасць спампоўвання
Памяншыце непатрэбны паралельны ціск на абмежаваны проксі і адрознівайце паралельнасць запытаў ад абмежаванняў злучэнняў на крыніцу.
Калі адзін запыт пакета працуе, але ўсталяванне дае тайм-аўты, параўнайце меншы аб'ём паралельнай працы па тым жа маршруце, перш чым замяняць проксі. Для версіі pnpm, якая падтрымлівае гэтыя налады праекта, сціплая дыягнастычная адпраўная кропка такая:
networkConcurrency: 8
maxsockets: 4Выкарыстоўвайце месца, якое падтрымліваецца ўсталяваным выпускам, напрыклад бягучы pnpm-workspace.yaml. Гэтыя лікі ілюстрацыйныя, а не вымярэнні ці рэкамендацыя па хуткасці для вашага проксі.
| Налада | Рэсурс |
|---|---|
networkConcurrency | Адначасовая сеткавая праца. |
maxsockets | Злучэнні на крыніцу: пратакол, хост і порт. |
Выканайце тую ж мэтавую аперацыю з пакетам і запішыце памылкі злучэння, завершаныя запыты і паўторы. Другое ўсталяванне з кэша нельга параўноўваць па прапускной здольнасці з першым спампоўваннем без кэша. Ніжэйшая паралельнасць можа дапамагчы абмежаванаму пасярэдніку або проста запаволіць здаровы запуск; без доказаў пра нагрузак няма пэўнага паляпшэння.
Праверце таксама паводзіны версіі. Бягучы pnpm дакументуе аўтаматычную паралельнасць і некаторыя карэкціроўкі, звязаныя з тайм-аўтамі, у тым ліку разгляд трафіку праз той жа проксі як аднаго хоста для гэтай карэкціроўкі. Яўная налада робіць эксперымент зразумелым, але не робіць планаванне ўсіх выпускаў аднолькавым.
Калі нават адзін запыт не ўдаецца, спачатку даследуйце пратакол, канчатковую кропку, аўтэнтыфікацыю, TLS або мэтавую палітыку. Абмежаванні паралельнасці не могуць выправіць гэтыя збоі.