Cloudflare Workers թե Vercel Functions․ 128 ՄԲ-ը բախվում է 4 ԳԲ-ին

21 հոկտեմբերի, 2026 թ., 12:00|Հեղինակ: QUASA-ի խմբագրական թիմ|6 րոպե ընթերցանություն

Cloudflare Workers-ի 128 ՄԲ հիշողությունը մեկ isolate-ի համար թեթև edge API-ի դեպքում սովորաբար ընդունելի է, մինչդեռ հիշողատար Node.js ֆունկցիայի համար ավելի հարմար ելակետ է Vercel Functions-ի Pro և Enterprise պլաններում հասանելի մինչև 4 ԳԲ հիշողությունը՝ request կամ response payload-ի 4,5 ՄԲ առանձին սահմանով։ Ավելի մեծ հիշողությունը, հետևաբար, դեռ չի նշանակում, որ մեծ ֆայլը կարելի է փոխանցել հենց ֆունկցիայի միջով։

Եթե endpoint-ը վերադարձնում է փոքր JSON պատասխան, հաճախ դիմում է արտաքին ծառայությունների կամ աշխատում է մեծ Node.js կախվածություններով, յուրաքանչյուր դեպքում որոշիչ սահմանը տարբեր է։ Հայաստանի օգտվողների համար կարևոր է նաև ամբողջ պատասխանի ժամանակը՝ ներառյալ տվյալների բազա և այլ API-ներ հասնելու ճանապարհը։ Կատարումը օգտվողին մոտ տեղակայելը ինքնին չի կրճատի հեռու տվյալների բազայի սպասումը։

Հիշողությունը և payload-ը տարբեր խնդիրներ են

Workers-ի սահմանը վերաբերում է isolate-ին, որի ներսում կարող են միաժամանակ սպասարկվել մի քանի հարցումներ։ Այդ հիշողության մեջ մտնում են JavaScript-ի heap-ը և WebAssembly-ի հատկացումները։ Եթե մի քանի հարցում միաժամանակ պահում են խոշոր օբյեկտներ, ընդհանուր սպառումը կարող է բարձրանալ, թեև յուրաքանչյուր առանձին հարցման պատասխանը փոքր է։ Այդ պատճառով միայն մեկ հարցման տվյալների չափով որոշել, թե կոդը կտեղավորվի՞ Workers-ում, բավարար չէ։

Մեծ մուտքային տվյալը հնարավոր է մշակել հոսքով՝ առանց ամբողջ մարմինը հիշողության մեջ հավաքելու։ Նույնը վերաբերում է պատասխանին. հոսքային արտածումը կարող է նվազեցնել հիշողության առավելագույն սպառումը։ Սա չի փոխում Workers-ի request body-ի առանձին սահմանը, որը կախված է Cloudflare հաշվի պլանից։ Եթե գործառույթը պարտադիր պետք է ամբողջ ֆայլը կամ փոխակերպվող տվյալների զանգվածը միաժամանակ պահի հիշողության մեջ, փոքր isolate-ը դառնում է ընտրությունը սահմանող հանգամանք։

Vercel-ի մեծ հիշողությունը տեղ է տալիս ծանր գրադարաններին, պատկերների կամ փաստաթղթերի մշակմանը և մեծ միջանկյալ տվյալներին։ Բայց նշված առավելագույնը սկզբնական հատկացումը չէ. այն պետք է կարգավորել համապատասխան վճարովի պլանում։ Բացի այդ, payload-ի սահմանը վերաբերում է ֆունկցիա մտնող կամ դրանից դուրս եկող HTTP մարմնին, այլ ոչ թե հաշվարկի համար հասանելի RAM-ին։ Խոշոր upload-ի դեպքում ֆայլը պահեստ ուղիղ ուղարկելը, իսկ ֆունկցիային միայն թույլտվությունն ու մետատվյալները վստահելը, շրջանցում է հենց այդ նեղ տեղը։

CPU ժամանակը մի շփոթեք ամբողջ հարցման տևողության հետ

Workers-ի CPU time-ը չափում է կոդի ակտիվ կատարումը. ցանցային պատասխանի, տվյալների բազայի կամ արտաքին API-ի սպասումը դրա մեջ չի մտնում։ Վճարովի պլանում մեկ HTTP հարցման համար այդ սահմանը կարգավորվում է, մինչդեռ կապի ամբողջ տևողությունը չափվում է առանձին։ Հետևաբար դանդաղ պատասխանող agent backend-ը պարտադիր չէ, որ CPU-ի սահմանին մոտ լինի։ Խնդիր կարող է առաջանալ այլ տեղում՝ սպասող հարցումների կուտակումից, միջանկյալ տվյալների հիշողությունից կամ հաճախորդի ընդհատած կապից։

Vercel-ի Fluid Compute-ը նույնպես առանձնացնում է ակտիվ CPU աշխատանքն արտաքին ծառայություններին սպասելուց, սակայն հաշվի է առնում նաև ֆունկցիայի համար հատկացված հիշողության օգտագործման տևողությունը։ Նրա գործարկման առավելագույն տևողությունը սահմանում է, թե որքան կարող է շարունակվել ամբողջ կանչը, ներառյալ սպասումն ու պատասխանի ուղարկումը։ Ուստի Workers-ի CPU ժամանակը Vercel-ի ամբողջ տևողության հետ համեմատելը սխալ եզրահանգման կհանգեցնի։ Նույն բեռի համար պետք է տարբերակել հաշվարկի, սպասման և հիշողության զբաղեցման ժամանակները։

Ինչ է փոխվում երեք բնորոշ բեռների դեպքում

Թեթև edge API

Թույլտվության պարզ ստուգումը, հարցման վերնագրերի փոփոխումը կամ փոքր JSON պատասխանը Workers-ի համար բնական աշխատանք է։ Նման endpoint-ում հիշողության մեծ պաշար սովորաբար պետք չէ, իսկ ակտիվ հաշվարկը կարճ է։ Եթե պատասխանի համար ամեն անգամ հարկավոր է դիմել մեկ այլ տարածաշրջանի տվյալների բազայի, օգտվողին մոտ runtime-ը կարող է ամբողջ հարցման միայն փոքր մասն արագացնել։ Հայաստանյան SaaS թիմի համար այստեղ վճռորոշը օգտվողից մինչև endpoint և ապա մինչև տվյալների աղբյուր ամբողջ շղթայի ուշացումն է։

Արտաքին ծառայություններին սպասող agent backend

Մոդելի, որոնման և տվյալների բազայի հաջորդական կանչերով backend-ը կարող է երկար սպասել՝ քիչ CPU ծախսելով։ Workers-ը տեղին է, երբ միջանկյալ պատասխանները փոքր են կամ հոսքային, իսկ օգտագործվող գրադարանները համատեղելի են դրա runtime-ի հետ։ Vercel Functions-ը նույնպես հարմար է I/O-ին սպասող կոդի համար, հատկապես եթե նախագիծն արդեն կառուցված է Node.js միջավայրի շուրջ։ Այստեղ հիշողության զբաղեցման տևողությունը, միաժամանակյա հարցումները և արտաքին ծառայությունների աշխարհագրությունը հաճախ ավելի օգտակար չափեր են, քան միայն ֆունկցիայի ակտիվ CPU ժամանակը։

Մեծ Node.js կախվածություններով ֆունկցիա

PDF գեներացումը, ծանր փոխակերպումը կամ մեծ dependency tree-ը ընտրությունը հաճախ թեքում են դեպի Vercel-ի Node.js runtime։ Առավելագույն հիշողությունն օգնում է միայն այն դեպքում, երբ ֆունկցիայի կոդն ու անհրաժեշտ ֆայլերը տեղավորվում են նաև deployment bundle-ի սահմանում, իսկ մուտքային և ելքային մարմինները՝ payload-ի սահմանում։ Ծրագրի երեք չափերը՝ գործարկման հիշողությունը, տեղակայվող փաթեթը և HTTP տվյալների մարմինը, պետք է գնահատել առանձին։ Եթե մշակումը հնարավոր է բաժանել փոքր անկախ աշխատանքների, Workers-ը կարող է նորից դառնալ կիրառելի տարբերակ։

Node.js համատեղելիությունը որոշվում է գործածվող API-ով

Cloudflare-ի Node.js համատեղելիության ցանկը տարբերակում է ամբողջությամբ աջակցվող, մասնակի աջակցվող և միայն ներմուծման համար հասանելի չաշխատող մոդուլները։ Նոր compatibility date-երով աջակցությունը միանում է լռելյայն, սակայն դա Workers-ը չի դարձնում սովորական Node.js գործընթաց։ Փաթեթը կարող է հաջողությամբ ներմուծվել, իսկ արտադրական ճանապարհում գործածվող կոնկրետ մեթոդը՝ սխալ առաջացնել։

Այս տարբերությունը մեծանում է, երբ framework-ը կամ դրա plugin-ները ներսում կանչում են API-ներ, որոնք ծրագրի սեփական կոդում չեն երևում։ Միայն package-ի տեղադրումն ու build-ի ավարտը համատեղելիության ապացույց չեն. նշանակություն ունի հենց գործարկվող ուղին։ Vercel-ի Node.js runtime-ը ավելի ուղիղ ընտրություն է այն նախագծի համար, որը կախված է Node.js-ի ամբողջ API ծածկույթից։ Workers-ի դեպքում անհրաժեշտ է նաև հաշվի առնել, որ համատեղելի գրադարանը կարող է գործել ճիշտ, բայց իր հիշողության պահանջով այլևս չտեղավորվել isolate-ում։

Արժեքը կախված է նույն բեռի չափերից

Cloudflare-ի Workers Paid Standard սակագինը սկսվում է ամսական $5-ից, ներառում է ամսական 10 մլն հարցում և 30 մլն CPU-միլիվայրկյան, իսկ այդ ծավալներից հետո հարցումներն ու CPU ժամանակը գանձվում են առանձին. տվյալների ելքի համար առանձին վճար չկա։ Այս կառուցվածքում հաճախ կանչվող, բայց քիչ հաշվարկ կատարող API-ն կարող է կանխատեսելի ծախս ունենալ։ Ընդհակառակը, հազվադեպ կանչվող ծանր հաշվարկը կարող է արագ սպառել ներառված CPU ժամանակը։

Պայմանական օրինակով՝ եթե ամսական բոլոր ներառված հարցումները միջինում սպառեն երեք միլիվայրկյան CPU, ամբողջ ներառված CPU ծավալը կօգտագործվի։ Սպասման երկարությունը այդ հաշվարկը չի մեծացնի, բայց գործնական պատասխանի ժամանակը միևնույն է կարող է երկար լինել։ Vercel-ի վճարովի օգտագործման դեպքում ակտիվ CPU-ից բացի նշանակություն ունի նաև հատկացված հիշողության ժամանակը. արտաքին API-ին սպասող ֆունկցիան շարունակում է զբաղեցնել հիշողությունը։ Միայն ամսական հարցումների թիվը, հետևաբար, երկու հարթակների գինը համեմատելու համար բավարար մուտքային տվյալ չէ։

Ինչ է ցույց տալիս հրապարակված փոքր չափումը

Մ. Քաշան Աշրաֆի հրապարակած փոքր փորձը պարզ JSON տրամաբանությունը տեղակայել է Vercel-ի անվճար պլանի Next.js API route-ում և Cloudflare Worker-ում, ապա Ֆրանկֆուրտի մեկ VPS-ից k6-ով բեռնել է դրանք 30 վայրկյան՝ թիրախավորելով վայրկյանում 100 հարցում. հաշվետվությունում API route-ի 99-րդ տոկոսի ուշացումը Workers-ի համար 55 մվ է, Vercel-ի համար՝ 78 մվ։ Այդ արդյունքը վերաբերում է տվյալ կոդին, տեղակայմանը և փորձի վայրին։ Այն չի չափում Հայաստանից հասանելիությունը, հեռու տվյալների բազան կամ հիշողատար dependency tree-ը։

Համեմատության անվճար պլանների աղյուսակը Vercel Hobby-ի հիշողության և Workers Free-ի CPU սահմանների համար պաշտոնական փաստաթղթերից տարբերվող թվեր է տալիս։ Ուստի այդ աղյուսակը սակագին ընտրելու հիմք չէ, իսկ հրապարակված ուշացումը պետք է դիտարկել որպես մեկ փոքր բեռի դիտարկում։ Թեթև API-ի դեպքում այն հուշում է, թե ինչու է edge տեղակայումը հետաքրքիր, բայց agent backend-ի և ծանր Node.js ֆունկցիայի ընտրությունը որոշվում է դրանց սեփական հիշողությամբ, սպասումով, կախվածություններով ու տվյալների տեղակայմամբ։

Կարդացեք նաև:

Կիսվել: