Ä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.

Mutta mikä on säie ja miten se eroaa prosessista? Eroja on useita, mutta tärkein niistä on se, miten niille varataan muistia. Voit ajatella prosessia kuin sovellusta. Jokaisen prosessin sisällä on vain tälle prosessille varattu osa muistia. Yksi prosessi ei siis pääse käsiksi toisen prosessin muistiin, ja tämä ominaisuus takaa korkean turvallisuuden. Jotta prosessien välille voidaan luoda viestintä, meidän on tehtävä jonkin verran työtä. Säikeet ovat erilaisia. Säikeet toimivat prosessin sisällä ja jakavat saman muistin, joten säikeiden tietojen jakaminen ei ole lainkaan ongelma.

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ä