MAMA! Viņš atkal bloķēja pavedienus!

Diegi

Galvenais, kas jāatceras: ir divu veidu pavedieni. Node.js: Galvenais pavediens - ko apstrādā Notikumu cilpa, un Darbinieku kopums (pavedienu pūls) - kas ir pavedienu pūls -
paldies libuv. Katram no viņiem ir atšķirīgs darbs. Pirmā uzdevums ir apstrādāt nebloķējošas I/O operācijas, bet otrais ir atbildīgs par CPU intensīvu darbu un arī bloķējošām I/O operācijām.

Bet kas ir pavediens un ar ko tas atšķiras no procesa? Atšķirības ir vairākas, bet vissvarīgākā no tām ir tā. mums ir tas, kā tiem tiek piešķirta atmiņa. Par procesu var domāt kā par lietojumprogrammu. Katra procesa iekšienē ir atmiņa, kas paredzēta tikai šim procesam. Tātad vienam procesam nav piekļuves otra procesa atmiņai, un šī īpašība nodrošina augstu drošību. Lai nodibinātu saziņu starp procesiem, mums ir jāveic zināms darbs. Pavedieni ir atšķirīgi. Pavedieni darbojas vienā procesā un koplieto vienu un to pašu atmiņu, tāpēc nav nekādu problēmu ar pavedienu koplietošanu. dati.

Tomēr viens jautājums rada problēmu. To sauc par sacīkšu stāvokli. Vītnes var darboties vienlaicīgi, tad kā mēs varam zināt, kura beigsies pirmā? Var gadīties, ka pirmajā palaišanas reizē pirmā operācija beidzas pirmā, bet nākamajā reizē var izrādīties otrādi un otrā operācija beidzas pirms pirmās. Iedomājieties, kā šādos apstākļos var strādāt ar rakstīšanas/lasīšanas operācijām! Košs murgs! Dažreiz ir ļoti grūti uzrakstīt pareizu kods daudzpavedienu vidē.

Turklāt daudzpavedienu valodām ir liela atmiņas pieskaitāmība, jo tās katram pieprasījumam izveido atsevišķu pavedienu; tātad, ja vēlaties izsaukt 1000 pieprasījumus, tās izveido 1000 pavedienus.

Kā risināt šādu problēmu? Tā vietā izmantojiet vienu pavedienu! Un tas ir tas, ko Mezgls piedāvā.

Kā JavaScript izstrādātājs Es aicinu jūs noskatīties filma
kurā Bārts Belderis skaidri izskaidro notikumu cilpas jēdzienu. Iepriekš minētā diagramma ir ņemta no viņa prezentācijas. Un, ja jūs vispār nezināt šos terminus, gan Mezgls un Libuv ir lieliska dokumentācija 🙂

Par bloķēšanu

In JavaScript attīstība nozare viņi saka, ka tāpēc, ka Mezgls ir vienpavedienu un bez bloķēšanas, ar tiem pašiem resursiem var panākt lielāku vienlaicīgumu nekā ar daudzpavedienu risinājumiem. Tā ir taisnība, bet tas nav tik skaisti un vienkārši, kā varētu šķist.

Tā kā Node.js ir viena pavediena (JS daļa), CPU ietilpīgi uzdevumi bloķēs visus notiekošos pieprasījumus, līdz konkrētais uzdevums tiks pabeigts. Tātad ir taisnība, ka Node.js var bloķēt katru pieprasījumu tikai tāpēc, ka vienā no tiem ir bloķēšanas instrukcija. Bloķēšanas kods nozīmē, ka tā izpildei ir nepieciešamas vairāk nekā dažas milisekundes. Taču nejauciet ilgu atbildes laiku ar bloķēšanu. Atbilde no datubāzes var aizņemt ļoti ilgu laiku, bet tas nebloķē jūsu procesu (lietojumprogrammu).

Bloķēšanas metodes tiek izpildītas sinhroni, bet nebloķēšanas metodes tiek izpildītas asinhroni.

Kā palēnināt (vai bloķēt) notikumu cilpu?

• neaizsargāta regulārā izteiksme - neaizsargāta regulārā izteiksme ir tā, kurai jūsu regulārās izteiksmes dzinējs var aizņemt eksponenciālu laiku; par to varat lasīt vairāk. šeit,
• JSON operācijas ar lieliem objektiem,
• izmantojot sinhrono API no Mezgls kodola moduļu asinhrono versiju vietā; visas Node.js standarta bibliotēkas I/O metodes nodrošina arī asinhronās versijas,
• citas programmēšanas kļūdas, piemēram, sinhronas bezgalīgas cilpas.

Vai tādā gadījumā, tā kā Worker Pool izmanto pavedienu kopumu, ir iespējams bloķēt arī tos? Diemžēl jā 🙁 Mezgls ir balstīta uz filozofiju. viens pavediens daudziem klientiem. Pieņemsim, ka konkrētais uzdevums, ko veic konkrēts darbinieks, ir ļoti sarežģīts un tā izpildei nepieciešams vairāk laika. Rezultātā šis Worker tiek bloķēts, un to nevar izmantot neviena cita neizpildīta uzdevuma izpildei, kamēr nav izpildīti tā norādījumi. Kā jūs jau droši vien nojaušat, tas var ietekmēt veiktspēju. Šādas problēmas var novērst, samazinot uzdevumu izpildes laika svārstības, izmantojot uzdevumu dalīšanu.

Secinājums

Noteikti izvairieties no bloķēšanas. Ja vien varat, vienmēr izvēlieties standarta bibliotēkas API asinhronās versijas. Pretējā gadījumā pēc jūsu lietotnes palaišanas klientam var rasties vairākas problēmas, sākot ar pazeminātu caurlaidspēju un beidzot ar pilnīgu atteikšanos, kas no lietotāja viedokļa ir liktenīga.

Lasīt vairāk:

Kāpēc jums (iespējams) vajadzētu izmantot Typescript

Kā nenogalināt projektu ar sliktu kodēšanas praksi?

Datu iegūšanas stratēģijas NextJS