EMA! Ta blokeeris jälle teemasid!

Niidid

Peamine asi, mida tuleb meeles pidada: on olemas kahte tüüpi niidid. Node.js: Main Thread - millega tegeleb Sündmuse tsükkelja Töötajate reserv (niidipool) - mis on niidipool -
tänu libuvile. Igaühel neist on erinev töö. Esimese eesmärk on tegeleda mitteblokeerivate I/O-operatsioonidega ja teine vastutab CPU-intensiivse töö ja samuti blokeerivate I/O-operatsioonide eest.

Aga mis on niit ja kuidas see erineb protsessist? Erinevusi on mitmeid, kuid meie jaoks on kõige olulisem see, kuidas neile mälu eraldatakse. Protsessist võib mõelda nagu rakendusest. Iga protsessi sees on üks tükike mälu, mis on pühendatud ainult sellele protsessile. Seega ei ole ühel protsessil ligipääsu teise protsessi mälule ja see omadus tagab kõrge turvalisuse. Et luua nendevaheline side, peame tegema mõningaid töid. Niidid on erinevad. Niidid jooksevad protsessi sees ja jagavad sama mälu, seega ei ole üldse probleemi, et niidid jagavad andmeid.

Üks küsimus tekitab siiski probleemi. Seda nimetatakse võidujooksu tingimuseks. Niidid võivad töötada korraga, nii et kuidas me teame, milline lõpeb esimesena? Võib juhtuda, et esimesel korral lõpeb esimene operatsioon esimesena, kuid järgmisel korral võib juhtuda vastupidi ja teine operatsioon lõpeb enne esimest. Kujutage ette tööd kirjutamis-/lugemisoperatsioonidega sellistes tingimustes! Õudusunenägu! Mõnikord on väga raske kirjutada korrektset kood mitmesuunalises keskkonnas.

Samuti on mitmelõngalistel keeltel suur mälu koormus, sest nad loovad iga taotluse jaoks eraldi niidi; seega, kui soovite kutsuda 1000 taotlust, loovad nad 1000 niiti.

Kuidas sellise probleemiga toime tulla? Kasutage hoopis ühte lõnga! Ja see ongi see, mida Sõlme pakub teile.

Nagu JavaScript arendaja Ma julgustan teid vaatama film
milles Bart Belder selgitab selgelt sündmuse tsükli mõistet. Ülaltoodud diagramm on võetud tema ettekandest. Ja kui te ei tea neid mõisteid üldse, siis nii Sõlme ja Libuvil on suurepärane dokumentatsioon 🙂

Blokeerimisest

Veebilehel JavaScript arendus tööstus ütlevad, et kuna Sõlme on ühetäheline ja mitteblokeeriv, saab sama ressursiga saavutada suurema samaaegsuse kui mitmeläheliste lahenduste puhul. See on tõsi, kuid see ei ole nii ilus ja lihtne, kui see võib tunduda.

Kuna Node.js on ühetäheline (JS osa), blokeerivad protsessorimahukad ülesanded kõik käimasolevad päringud, kuni konkreetne ülesanne on lõpetatud. Seega on tõsi, et Node.js saate blokeerida kõik taotlused lihtsalt sellepärast, et ühes neist oli blokeeriv käsk sees. Blokeeriv kood tähendab, et selle lõpetamine võtab rohkem kui paar millisekundit. Kuid ärge ajage pikka reageerimisaega segi blokeerimisega. Andmebaasi vastus võib võtta väga kaua aega, kuid see ei blokeeri teie protsessi (rakendust).

Blokeerivad meetodid täidetakse sünkroonselt ja mitteblokeerivad meetodid asünkroonselt.

Kuidas saab aeglustada (või blokeerida) oma sündmuste tsüklit?

• haavatav regex - haavatav regulaaravaldis on see, mille puhul teie regulaaravaldise mootor võib võtta eksponentsiaalselt aega; nende kohta saate lugeda mare'i. siin,
• JSON-operatsioonid suurte objektidega,
• kasutades sünkroonseid APIsid alates Sõlme tuumamoodulid asünkroonsete versioonide asemel; kõik Node.js standardraamatukogu I/O meetodid pakuvad ka oma asünkroonseid versioone,
• muud programmeerimisvead, näiteks sünkroonne lõpmatu tsükkel.

Kas sellisel juhul, kuna Worker Pool kasutab niitide kogumit, on võimalik ka neid blokeerida? Kahjuks jah 🙁 Sõlme põhineb filosoofial üks niit paljude klientide jaoks. Oletame, et konkreetse Töötaja poolt täidetav ülesanne on väga keeruline ja vajab rohkem aega. Selle tulemusena on Worker blokeeritud ja teda ei saa kasutada teiste pooleliolevate ülesannete täitmiseks, kuni tema juhised on täidetud. Nagu te ilmselt juba arvasite, võib see mõjutada jõudlust. Selliseid probleeme saab vältida, kui vähendada ülesannete aegade varieeruvust, kasutades ülesannete partitsioneerimist.

Kokkuvõte

Vältige blokeerimist, see on kindel. Kui te ainult saate, valige alati standardse raamatukogu API-de asünkroonseid versioone. Vastasel juhul võib kliendil pärast rakenduse käivitamist tekkida mitmeid probleeme, alustades halvenenud läbilaskevõimest ja lõpetades täieliku loobumisega, mis on kasutaja seisukohast fataalne.

Loe edasi:

Miks peaksite (tõenäoliselt) kasutama Typescript'i

Kuidas mitte tappa projekti halbade kodeerimistavadega?

NextJS-i andmete hankimise strateegiad