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.

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.

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