MAMMA! Han blockerade trådar igen!

Trådar

Det viktigaste att komma ihåg: det finns två typer av trådar i Node.js: Huvudtråd - som hanteras av Evenemangsslinga, och Arbetstagarpool (trådpool) - vilket är poolen med trådar -
tack vare libuv. Var och en av dem har olika uppgifter. Målet för den första är att hantera icke-blockerande I/O-operationer, och den andra ansvarar för CPU-intensivt arbete och även blockerande I/O.

Men vad är en tråd och hur skiljer den sig från en process? Det finns flera skillnader, men den viktigaste för oss är hur minnet allokeras till dem. Du kan tänka på en process som på en applikation. Inuti varje process finns det en bit minne som är dedikerad bara för den här processen. Så en process har inte tillgång till minnet för den andra, och den här egenskapen garanterar hög säkerhet. För att upprätta kommunikation mellan dem måste vi göra lite arbete. Trådar är annorlunda. Trådar körs inuti en process och delar samma minne, så det finns inga problem alls med att trådar delar data.

Men en fråga orsakar problem. Det kallas för race condition. Trådarna kan köras samtidigt, så hur vet vi vilken som slutar först? Det kan hända att första gången du kör den så slutar den första operationen först, och nästa gång kan det visa sig vara tvärtom och den andra operationen slutar före den första. Tänk dig att arbeta med skriv-/läsoperationer under sådana förhållanden! En mardröm! Det är ibland mycket svårt att skriva korrekta kod i en flertrådad miljö.

De flertrådade språken har också en stor minnesoverhead eftersom de skapar en separat tråd för varje förfrågan; så om du vill ringa 1000 förfrågningar skapar de 1000 trådar.

Hur hanterar man ett sådant problem? Använd en enda tråd istället! Och det är vad Nod erbjuder dig.

Som JavaScript utvecklare Jag uppmuntrar dig att titta på film
där Bart Belder tydligt förklarar konceptet med händelseslingan. Diagrammet ovan är hämtat från hans presentation. Och om du inte känner till dessa termer alls, både Nod och Libuv har utmärkt dokumentation 🙂 🙂

Om blockering

I JavaScript utveckling industrin säger de det för att Nod är enkeltrådad och icke-blockerande kan du uppnå högre samtidighet med samma resurser än med flertrådade lösningar. Det är sant, men det är inte så vackert och enkelt som det kan verka.

Sedan Node.js är enkeltrådad (JS-delen), kommer CPU-intensiva uppgifter att blockera alla pågående förfrågningar tills den specifika uppgiften är klar. Så det är sant att i Node.js kan du blockera varje begäran bara för att en av dem innehöll en blockeringsinstruktion. Blockeringskoden innebär att det tar mer än några millisekunder att slutföra. Men förväxla inte lång svarstid med blockering. Svaret från databasen kan ta mycket lång tid, men det blockerar inte din process (applikation).

Blockerande metoder körs synkront och icke-blockerande metoder körs asynkront.

Hur kan du sakta ner (eller blockera) din händelseslinga?

• sårbara reguljära uttryck - ett sårbart reguljärt uttryck är ett uttryck som kan ta exponentiell tid för din reguljära uttrycksmotor; du kan läsa mer om dem här,
• JSON-operationer på stora objekt,
• med hjälp av synkrona API:er från Nod kärnmoduler istället för asynkrona versioner; alla I/O-metoder i standardbiblioteket Node.js tillhandahåller också sina asynkrona versioner,
• andra programmeringsfel, som synkrona oändliga loopar.

I så fall, eftersom Worker Pool använder en pool av trådar, är det möjligt att blockera dem också? Tyvärr, ja 🙁 Nod bygger på en filosofi en tråd för många klienter. Låt oss anta att en viss uppgift som utförs av en specifik Worker är mycket komplex och behöver mer tid för att slutföras. Detta leder till att Workern blockeras och inte kan användas för att utföra någon av de andra väntande uppgifterna förrän dess instruktioner har utförts. Som du säkert har gissat vid det här laget kan det påverka prestandan. Du kan förhindra sådana problem genom att minimera variationen i Task-tider med hjälp av Task-partitionering.

Slutsats

Undvik blockering, det är helt säkert. Om du bara kan, välj alltid asynkrona versioner av standardbibliotekets API: er. Annars kan klienten efter att ha kört din app uppleva flera problem, som börjar med den försämrade genomströmningen och slutar med fullständig tillbakadragande, vilket är dödligt ur användarens perspektiv.

Läs mer om detta:

Varför du (förmodligen) bör använda Typescript

Hur undviker man att döda ett projekt med dåliga kodningsrutiner?

Strategier för datahämtning i NextJS