Cloudflare Workers vai Vercel: viens etalontests neizvēlas uzvarētāju

Cloudflare Workers un Vercel izvēlē viens SSR etalontests nenosaka uzvarētāju. Īsam API, kura kods darbojas Workers vidē, šīs platformas cenu modelis var būt izdevīgs; esošai Next.js lietotnei ar atkarību no Node.js bibliotēkām Vercel var prasīt mazāk pielāgojumu. Izšķiroša ir lietotnes saderība, datubāzes atrašanās vieta un izmaksas pie paredzamās slodzes.

Servera pusē ģenerētas lapas jeb SSR atbildes laiks ir tikai viena izvēles daļa. Tas ietver gan koda darbu, gan gaidīšanu tīklā un, ja maršruts izmanto datubāzi, arī datu iegūšanu. Tāpēc ātruma salīdzinājumā jāizmanto vienāds saturs un kešatmiņas stāvoklis, bet cenu aprēķinā jānodala pieprasījumu skaits, CPU laiks un funkcijas darbības ilgums.

Ko izmērīja publiskais SSR tests

Publiskajā SSR etalontestā katrai ietvara un platformas kombinācijai veikti 100 atkārtojumi: Next.js konfigurācijas vidējais atbildes laiks bija 0,534 sekundes Vercel un 1,895 sekundes Cloudflare pusē, bet Vercel funkcijai bija piešķirti 2 vCPU un 4 GB atmiņas. Rezultāts raksturo šos izvietojumus un testa slodzi. Atšķirīgie resursu nosacījumi neļauj no tā vien izsecināt, kura izpildvide būs ātrāka pie vienādiem resursiem vai citas lietotnes koda.

Testa klienta izmērītajā laikā ietilpst ceļš līdz funkcijai un atpakaļ. Lietotāja pieredzei tas ir būtisks lielums, taču tas nav tas pats, kas funkcijas CPU patēriņš. Ja SSR maršruts pārsvarā gaida datubāzes vaicājumu, procesora slodzes tests maz pasaka par šā maršruta pilno atbildes laiku.

Cloudflare etalontesta analīzē norāda, ka atsevišķajā React SSR testā Workers pusē nebija iestatīts NODE_ENV, tāpēc React darbojās izstrādes režīmā; analīzē skaidrota arī tīkla attāluma un straumju adapteru ietekme. React konfigurācijas kļūda pati par sevi neizskaidro minēto Next.js vidējo laiku. Toties tā parāda, kā viens iestatījums var mainīt salīdzināmo darbu, kamēr adapteru izmaksas var ietekmēt tieši Next.js izvietojumu.

Par ko katra platforma izraksta rēķinu

Cloudflare Workers cenu tabulā maksas plāna minimālā maksa ir 5 ASV dolāri mēnesī: tajā ietilpst 10 miljoni pieprasījumu un 30 miljoni CPU milisekunžu, bet papildu miljons pieprasījumu maksā 0,30 dolārus un papildu miljons CPU milisekunžu — 0,02 dolārus. Gaidīšanas ilgums pats par sevi nav CPU patēriņš. Pieprasījums, ko apkalpo Workers kešatmiņa, joprojām tiek ieskaitīts pieprasījumu skaitā, taču bez funkcijas izpildes netērē tās CPU laiku.

Vercel Functions tarifi paredz vienu miljonu iekļautu izsaukumu Hobby plānā, savukārt Pro plānā izsaukumi tiek uzskaitīti no pirmās vienības par 0,60 dolāriem miljonā; Frankfurtes reģionā aktīvā CPU likme ir 0,184 dolāri stundā, bet piešķirtās atmiņas likme — 0,0152 dolāri par GB stundu. CPU uzskaite apstājas, kamēr kods gaida ārēju pakalpojumu. Atmiņa tikmēr tiek uzskaitīta visā funkcijas instances aktīvajā laikā, arī gaidot datubāzi; viena instance var vienlaikus apkalpot vairākus pieprasījumus.

Vercel Pro plāna noteikumi paredz 20 dolāru mēneša platformas maksu un tikpat lielu izmantošanas kredītu. Kredīts sedz arī funkciju patēriņu, ja to nav izlietojuši citi komandas resursi. Tādēļ Pro cenu nevar aprēķināt, vienkārši atņemot Hobby plānā iekļautos izsaukumus, un mazu funkcijas izmaksu nevar pielīdzināt visa Pro konta rēķinam.

Divi vienādas slodzes aprēķini

Abos nosacītajos piemēros katra platforma saņem vienādu pieprasījumu skaitu un katram pieprasījumam veic vienādu CPU darbu. Vercel funkcija darbojas Frankfurtē ar 1 GB piešķirtās atmiņas; pieņemts, ka pieprasījumi nepārklājas un instances uzskaitītais aktīvais laiks sakrīt ar norādīto atbildes ilgumu. Šis pieņēmums ļauj pārskatāmi salīdzināt tarifus, lai gan reālā slodzē vienlaicīgi pieprasījumi var samazināt uzskaitītās atmiņas stundas uz vienu izsaukumu.

• Nosacīts viegls API saņem 5 miljonus pieprasījumu mēnesī; katrs patērē 5 ms CPU un ilgst 50 ms. Workers kopā patērē 25 miljonus CPU milisekunžu un iekļaujas 5 dolāru mēneša maksā. Vercel aprēķinātā funkcijas izmantošana ir aptuveni 5,33 dolāri: 3 dolāri par izsaukumiem, 1,28 par CPU un 1,06 par atmiņu. Ja Pro kredīts ir pilnībā pieejams, kopējā platformas maksa šajos pieņēmumos paliek 20 dolāri.
• Nosacīts smagāks SSR saņem 20 miljonus pieprasījumu; katrs patērē 20 ms CPU un ilgst 200 ms. Workers summa ir 15,40 dolāri: 5 dolāru pamatmaksa, 3 dolāri par papildu pieprasījumiem un 7,40 par papildu CPU laiku. Vercel funkcijas izmantošana ir aptuveni 49,33 dolāri: 12 par izsaukumiem, 20,44 par CPU un 16,89 par atmiņu. Ar pilnībā pieejamu Pro kredītu šajā piemērā kopējā maksa ir aptuveni 49,33 dolāri, jo funkcijas izmantošana pārsniedz kredītu.

Tie ir tarifu aprēķini, nevis novēroti klientu rēķini. Tajos nav datubāzes, datu pārraides, citu pakalpojumu vai nodokļu izmaksu. Ja funkcija ilgāk gaida datubāzi, Vercel atmiņas izmaksas šādā nepārklājošos pieprasījumu modelī pieaug arī bez papildu CPU darba; ja atbildi apkalpo kešatmiņa, funkcijas izsaukumu skaits var kristies. Tādēļ abām formulām vajadzīgi konkrētās lietotnes, nevis publiska CPU testa laiki.

Kā iegūt salīdzināmu savas lietotnes rezultātu

Reproducējamam SSR testam jādefinē viens maršruts, viena datu kopa un vienāds atbildes saturs. Vispirms jāizlemj, vai tiek mērīta tikai lapas ģenerēšana vai arī datubāzes vaicājums. Ja vienā izvietojumā atbilde nāk no kešatmiņas, bet otrā tiek ģenerēta no jauna, abi mērījumi raksturo atšķirīgu darbu.

1. Izvieto produkcijas būvējumus. Pieraksti ietvara un adaptera versiju, funkcijai piešķirtos resursus un vides mainīgos, kas ietekmē SSR darbību, īpaši NODE_ENV.
2. Abām versijām izmanto vienādu datubāzes saturu un pieraksti datubāzes un funkcijas reģionu. Atsevišķi mēri maršrutu bez datubāzes un maršrutu ar reālu vaicājumu.
3. No Latvijas un vēl viena lietotājiem nozīmīga reģiona sūti vienādu pieprasījumu secību. Nošķir pirmos pieprasījumus no atkārtotiem, pārbaudi atbildes saturu un pieraksti gan tipisko laiku, gan lēnākās atbildes.
4. Salīdzini laiku līdz pirmajam baitam, pilnas atbildes laiku, CPU patēriņu un datubāzes vaicājuma ilgumu. Cenu formulās izmanto funkcijas uzskaitītos resursus, nevis pieņem, ka pilns HTTP atbildes laiks ir CPU laiks.

Datubāze un Node.js nosaka izvēles robežas

Latvijas lietotājam tuvs izpildes punkts var saīsināt pirmo tīkla posmu. Ja SSR funkcija pēc tam pieprasa datus no attāla reģiona, kopējais laiks var pieaugt. Tāpēc rezultātā jāredz abi attālumi: no lietotāja līdz funkcijai un no funkcijas līdz datubāzei. API bez ārēja datu avota un SSR lapa ar vairākiem vaicājumiem var dot atšķirīgu platformu secību.

Esošai Node.js lietotnei saderība ir atsevišķs lēmuma slieksnis. Ja kritiska bibliotēka vai tās izmantotā API Workers vidē prasa pielāgojumu, lētāks funkcijas tarifs neietver šā darba izmaksas. Ja produkcijas būvējums un svarīgie maršruti tur darbojas korekti, cenu un veiktspējas salīdzinājumu var turpināt. Next.js gadījumā jāfiksē arī adapteris, jo tas piedalās SSR atbildes veidošanā.

Izvēles secība ir vienkārša: vispirms pārbaudīt koda darbību abās vidēs, tad izmērīt lietotājiem svarīgos maršrutus kopā ar paredzēto datubāzi un tikai pēc tam ievietot izmērīto CPU laiku, darbības ilgumu un pieprasījumu prognozi tarifu aprēķinā. Šāda secība dod lēmumu par lietotni, kuru paredzēts izvietot, nevis par etalontesta konfigurāciju.

Lasiet arī:

• Wise Business vai Revolut Business: neregulāri maksājumi maina uzvarētāju
• Metricool vai Buffer: kontu skaits apgriež cenas salīdzinājumu
• Zoom vai Google Meet: klientu sapulces un Workspace nosaka uzvarētāju