MOM! Han har blokeret tråde igen!

Tråde

Det vigtigste at huske: Der er to typer tråde i Node.js: Hovedtråd - som håndteres af Begivenheds-loopog Arbejderpulje (trådpulje) - som er puljen af tråde -.
takket være libuv. Hver af dem har et forskelligt job. Målet for den første er at håndtere ikke-blokerende I/O-operationer, og den anden er ansvarlig for CPU-intensivt arbejde og også blokerende I/O.

Men hvad er en tråd, og hvordan adskiller den sig fra en proces? Der er flere forskelle, men den vigtigste for os er, hvordan hukommelsen allokeres til dem. Du kan tænke på en proces som på en applikation. I hver proces er der en del af hukommelsen, som kun er dedikeret til denne proces. Så den ene proces har ikke adgang til den andens hukommelse, og denne egenskab sikrer høj sikkerhed. For at etablere kommunikation mellem dem skal vi udføre noget arbejde. Tråde er anderledes. Tråde kører inde i en proces og deler den samme hukommelse, så der er slet ikke noget problem med, at tråde deler data.

Men én ting skaber problemer. Det kaldes race condition. Trådene kan køre på samme tid, så hvordan ved vi, hvilken der slutter først? Det kan ske, at den første gang du kører den, slutter den første operation først, og næste gang kan det vise sig at være det modsatte, og den anden operation slutter før den første. Forestil dig at arbejde med skrive-/læseoperationer under sådanne forhold! Et mareridt! Det er nogle gange meget svært at skrive korrekte Kode i et multi-threaded miljø.

De flertrådede sprog har også et stort hukommelsesoverhead, fordi de opretter en separat tråd for hver anmodning; så hvis du vil kalde 1000 anmodninger, opretter de 1000 tråde.

Hvordan håndterer man sådan et problem? Brug en enkelt tråd i stedet! Og det er, hvad Knudepunkt tilbyder dig.

Som en JavaScript Udvikler Jeg opfordrer dig til at se film
hvor Bart Belder tydeligt forklarer begrebet event loop. Ovenstående diagram er taget fra hans præsentation. Og hvis du slet ikke kender disse begreber, kan både Knudepunkt og Libuv har fremragende dokumentation 🙂.

Om blokering

I JavaScript udvikling industrien siger de, at fordi Knudepunkt er enkelttrådet og ikke-blokerende, kan du opnå højere samtidighed med de samme ressourcer end med flertrådede løsninger. Det er sandt, men det er ikke så smukt og nemt, som det måske ser ud til.

Siden Node.js er single-threaded (JS-delen), vil CPU-intensive opgaver blokere alle igangværende anmodninger, indtil den pågældende opgave er afsluttet. Så det er sandt, at i Node.js kan man blokere alle forespørgsler, bare fordi en af dem indeholder en blokerende instruktion. Den blokerende kode betyder, at det tager mere end et par millisekunder at afslutte. Men forveksl ikke lang svartid med blokering. Svaret fra databasen kan tage meget lang tid, men det blokerer ikke din proces (applikation).

Blokerende metoder udføres synkront, og ikke-blokerende metoder udføres asynkront.

Hvordan kan du gøre dit event-loop langsommere (eller blokere det)?

• sårbar regex - et sårbart regulært udtryk er det, som din regulære udtryksmotor kan bruge eksponentiel tid på; du kan læse mere om dem her,
• JSON-operationer på store objekter,
• ved hjælp af synkrone API'er fra Knudepunkt kernemoduler i stedet for asynkrone versioner; alle I/O-metoder i Node.js-standardbiblioteket indeholder også deres asynkrone versioner,
• andre programmeringsfejl, som f.eks. synkrone uendelige løkker.

I så fald, da Worker Pool bruger en pulje af tråde, er det så muligt at blokere dem også? Desværre, ja 🙁. Knudepunkt er baseret på en filosofi en tråd til mange klienter. Lad os antage, at en given opgave, der udføres af en bestemt Worker, er meget kompleks og kræver mere tid. Som følge heraf blokeres Workern, og den kan ikke bruges til at udføre andre ventende opgaver, før dens instruktioner er udført. Som du sikkert har gættet nu, kan det påvirke ydeevnen. Du kan forhindre sådanne problemer ved at minimere variationen i task-tider ved at bruge task-partitionering.

Konklusion

Undgå blokering, det er helt sikkert. Hvis du kun kan, skal du altid vælge asynkrone versioner af standardbibliotekets API'er. Ellers kan klienten efter at have kørt din app opleve flere problemer, der starter med forringet gennemstrømning og slutter med fuldstændig tilbagetrækning, hvilket er fatalt set fra brugerens perspektiv.

Læs mere om det:

Hvorfor du (sandsynligvis) bør bruge Typescript

Hvordan dræber man ikke et projekt med dårlig kodningspraksis?

Strategier for at hente data i NextJS