MAMA! Jis vėl užblokavo siūlus!

Siūlai

Pagrindinis dalykas, kurį reikia atsiminti: yra dviejų tipų gijos Node.js: Pagrindinis siūlas - kurį tvarko Įvykių ciklas, ir Darbuotojų rezervas (gijų fondas) - tai yra gijų fondas -
ačiū libuv. Kiekvienas iš jų dirba skirtingą darbą. Pirmojo tikslas - atlikti neblokuojančias įvesties ir išvesties operacijas, o antrojo - atlikti procesoriui imlų darbą ir blokuojančias įvesties ir išvesties operacijas.

Tačiau kas yra gija ir kuo ji skiriasi nuo proceso? Yra keletas skirtumų, tačiau svarbiausias iš jų mus yra tai, kaip jiems paskirstoma atmintis. Apie procesą galima galvoti kaip apie programą. Kiekvieno proceso viduje yra tik šiam procesui skirta atminties dalis. Taigi, vienas procesas neturi prieigos prie kito proceso atminties, ir ši savybė užtikrina didelį saugumą. Norėdami užmegzti tarpusavio ryšį, turime atlikti tam tikrą darbą. Gijos yra skirtingos. Gijos veikia proceso viduje ir dalijasi ta pačia atmintimi, todėl nėra jokių problemų, kai gijos dalijasi duomenys.

Tačiau kyla viena problema. Ji vadinama lenktynių sąlyga. Srautai gali būti paleisti tuo pačiu metu, tad kaip žinoti, kuris baigsis pirmas? Gali atsitikti taip, kad pirmą kartą paleidus, pirmoji operacija baigsis pirma, o kitą kartą gali paaiškėti priešingai ir antroji operacija baigsis anksčiau už pirmąją. Įsivaizduokite, kad tokiomis sąlygomis dirbate su įrašymo ir skaitymo operacijomis! Košmaras! Kartais labai sunku parašyti teisingą kodas kelių gijų aplinkoje.

Be to, daugiasluoksnės kalbos turi daug atminties sąnaudų, nes kiekvienai užklausai sukuria atskirą giją; taigi, jei norite iškviesti 1000 užklausų, jos sukuria 1000 gijų.

Kaip spręsti tokią problemą? Vietoj to naudokite vieną siūlą! Būtent tai Mazgas jums siūlo.

Kaip JavaScript kūrėjas Kviečiu žiūrėti filmas
kurioje Bartas Belderis aiškiai paaiškina įvykių kilpos koncepciją. Pateikta schema paimta iš jo pranešimo. O jei šių sąvokų visai nežinote, tiek Mazgas ir Libuv turi puikius dokumentus 🙂

Apie blokavimą

Svetainėje JavaScript plėtra pramonė jie sako, kad dėl to, kad Mazgas yra viengubas ir neblokuojamas, todėl su tais pačiais ištekliais galima pasiekti didesnį lygiagretumą nei naudojant daugiagubus sprendimus. Tai tiesa, tačiau tai nėra taip gražu ir paprasta, kaip gali atrodyti.

Nuo Node.js yra vienos gijos (JS dalis), procesoriui imlios užduotys blokuos visas vykdomas užklausas, kol konkreti užduotis bus baigta. Taigi, tiesa, kad Node.js galite blokuoti kiekvieną užklausą tik todėl, kad vienoje iš jų buvo blokuojanti instrukcija. Blokuojantis kodas reiškia, kad užtrunka ilgiau nei kelias milisekundes. Tačiau nepainiokite ilgo atsako laiko su blokavimu. Atsakymas iš duomenų bazės gali užtrukti labai ilgai, tačiau jis neužblokuoja jūsų proceso (paraiškos).

Blokuojantys metodai vykdomi sinchroniškai, o neblokuojantys - asinchroniškai.

Kaip galite sulėtinti (arba užblokuoti) įvykių ciklą?

• pažeidžiama regex - pažeidžiama reguliarioji išraiška yra tokia, kurią reguliariosios išraiškos variklis gali užtrukti eksponentiškai ilgai; apie tai galite paskaityti daugiau. čia,
• JSON operacijos su dideliais objektais,
• naudojant sinchronines API iš Mazgas vietoj asinchroninių versijų; visi Node.js standartinės bibliotekos I/O metodai taip pat turi asinchronines versijas,
• kitos programavimo klaidos, pavyzdžiui, sinchroninės begalinės kilpos.

Tokiu atveju, kadangi "Worker Pool" naudoja gijų fondą, ar galima jas taip pat blokuoti? Deja, taip 🙁 Mazgas grindžiamas filosofija viena gija daugeliui klientų. Tarkime, kad konkretaus darbuotojo atliekama užduotis yra labai sudėtinga ir jai atlikti reikia daugiau laiko. Dėl to "Worker" yra užblokuotas ir negali būti naudojamas kitoms laukiančioms užduotims vykdyti, kol nebus įvykdyti jo nurodymai. Kaip tikriausiai jau spėjote, tai gali turėti įtakos našumui. Tokių problemų galite išvengti sumažindami Užduočių laiko skirtumus, naudodami Užduočių suskirstymą.

Išvada

Be abejo, venkite blokavimo. Jei tik galite, visada rinkitės asinchronines standartinės bibliotekos API versijas. Priešingu atveju, paleidus jūsų programą, klientas gali susidurti su keliomis problemomis, pradedant sumažėjusiu pralaidumu ir baigiant visišku pasitraukimu, kuris vartotojo požiūriu yra pražūtingas.

Skaityti daugiau:

Kodėl turėtumėte (tikriausiai) naudoti Typescript

Kaip nesunaikinti projekto dėl blogos kodavimo praktikos?

Duomenų gavimo strategijos "NextJS