ÄITI! Hän esti taas viestiketjut!

Kierteet

Tärkein muistettava asia: on olemassa kahdenlaisia säikeitä vuonna Node.js: Main Thread - jota käsittelee Tapahtumasilmukkaja Työntekijäpooli (thread pool) - joka on säikeiden allas -
kiitos libuvin. Jokaisella heistä on erilainen tehtävä. Ensimmäisen tehtävänä on käsitellä lukkiutumattomia I/O-operaatioita, ja toinen vastaa CPU-intensiivisestä työstä ja myös lukkiutumattomasta I/O:sta.

But what is a thread and how it’s different than a process? There are several differences, but the most important one for us is how the memory is allocated to them. You can think about a process like about an application. Inside each process, there is a chunk of memory dedicated just for this process. So, one process doesn`t have access to the memory of the second one, and this property ensures high security. To establish communication between them, we must do some work. Threads are different. Threads runs inside a process and share the same memory so there is no problem at all with threads sharing data.

Yksi asia aiheuttaa kuitenkin ongelmia. Sitä kutsutaan kilpajuoksuehdoksi. Säikeet voivat toimia samaan aikaan, joten mistä tiedämme, kumpi päättyy ensin? Saattaa käydä niin, että ensimmäisellä kerralla ensimmäinen operaatio päättyy ensin, ja seuraavalla kerralla voi käydä päinvastoin ja toinen operaatio päättyy ennen ensimmäistä. Kuvittele työskentely kirjoitus/lukuoperaatioiden kanssa tällaisissa olosuhteissa! Painajainen! Joskus on hyvin vaikeaa kirjoittaa oikeita koodi monisäikeisessä ympäristössä.

Lisäksi monisäikeisissä kielissä on suuri muistin kuluminen, koska ne luovat erillisen säikeen jokaista pyyntöä varten. Jos siis haluat kutsua 1000 pyyntöä, ne luovat 1000 säiettä.

Miten käsitellä tällaista ongelmaa? Käytä sen sijaan yhtä säiettä! Ja se on se, mitä Solmu tarjoaa sinulle.

Koska JavaScript kehittäjä Kehotan teitä katsomaan elokuva
jossa Bart Belder selittää selkeästi tapahtumasilmukan käsitteen. Yllä oleva kaavio on otettu hänen esityksestään. Ja jos et tunne näitä termejä lainkaan, niin molemmat Solmu ja Libuvilla on erinomainen dokumentaatio 🙂

Tietoja estämisestä

Osoitteessa JavaScript-kehitys teollisuudessa sanotaan, että koska Solmu on yksisäikeinen ja ei-blokkaava, voit saavuttaa suuremman samanaikaisuuden samoilla resursseilla kuin monisäikeisillä ratkaisuilla. Se on totta, mutta se ei ole niin kaunista ja helppoa kuin miltä se saattaa vaikuttaa.

Koska Node.js on yksisäikeinen (JS-osio), suorittimen kuormittavat tehtävät estävät kaikki käynnissä olevat pyynnöt, kunnes kyseinen tehtävä on suoritettu loppuun. On siis totta, että Node.js voit estää kaikki pyynnöt vain siksi, että yhdessä niistä oli estävä käsky. Estävä koodi tarkoittaa, että sen suorittaminen kestää yli muutaman millisekunnin. Älä kuitenkaan sekoita pitkää vasteaikaa estämiseen. Tietokannan vastaus voi kestää hyvin kauan, mutta se ei estä prosessia (sovellusta).

Estävät menetelmät suoritetaan synkronisesti ja ei-estävät menetelmät asynkronisesti.

Miten voit hidastaa (tai estää) tapahtumasilmukkaa?

• haavoittuva regex - haavoittuva säännöllinen lauseke on sellainen, johon säännöllinen lausekkeesi voi viedä eksponentiaalisen paljon aikaa; voit lukea niistä lisää. täällä,
• JSON-operaatiot suurille objekteille,
• käyttämällä synkronisia API:ita Solmu ydinmoduulit asynkronisten versioiden sijaan; kaikista Node.js-standardikirjaston I/O-menetelmistä on myös niiden asynkroniset versiot,
• muut ohjelmointivirheet, kuten synkroniset loputtomat silmukat.

Koska Worker Pool käyttää säikeiden joukkoa, onko tässä tapauksessa mahdollista estää myös ne? Valitettavasti kyllä 🙁 Solmu perustuu filosofiaan yksi säie monille asiakkaille. Oletetaan, että tietyn työntekijän suorittama tehtävä on hyvin monimutkainen ja vaatii enemmän aikaa. Tämän seurauksena Worker on estynyt, eikä sitä voida käyttää muiden vireillä olevien tehtävien suorittamiseen ennen kuin sen ohjeet on suoritettu. Kuten olet luultavasti jo arvannut, se saattaa vaikuttaa suorituskykyyn. Voit estää tällaiset ongelmat minimoimalla tehtävien aikojen vaihtelun käyttämällä tehtävien osiointia.

Päätelmä

Vältä estämistä, se on varmaa. Jos vain voit, valitse aina asynkroniset versiot standardikirjaston API:ista. Muuten sovelluksesi suorittamisen jälkeen asiakas voi kokea useita ongelmia, jotka alkavat heikentyneestä läpäisykyvystä ja päättyvät täydelliseen peruuttamiseen, mikä on käyttäjän kannalta kohtalokasta.

Lue lisää:

Miksi sinun pitäisi (luultavasti) käyttää Typescriptiä?

Miten projektia ei saa tappaa huonoilla koodauskäytännöillä?

Tiedonhakustrategiat NextJS:ssä