MAMINKA! Zase zablokoval vlákna!

Vlákna

Hlavní věc, kterou je třeba si zapamatovat: existují dva typy vláken v. Node.js: Hlavní vlákno - o které se stará Smyčka událostía Bazén pracovníků (thread pool) - což je fond vláken -
díky libuv. Každý z nich má jinou práci. Úkolem prvního z nich je zpracovávat neblokované I/O operace a druhý je zodpovědný za práci náročnou na procesor a také za blokování I/O operací.

Co je to ale vlákno a v čem se liší od procesu? Rozdílů je několik, ale nejdůležitější je, že se liší nás je způsob, jakým je jim přidělována paměť. O procesu můžete uvažovat jako o aplikaci. Uvnitř každého procesu je kus paměti vyhrazený právě pro tento proces. Jeden proces tedy nemá přístup k paměti druhého procesu a tato vlastnost zajišťuje vysokou bezpečnost. Abychom mezi nimi mohli navázat komunikaci, musíme udělat určitou práci. Vlákna se liší. Vlákna běží uvnitř procesu a sdílejí stejnou paměť, takže se sdílením dat mezi vlákny není vůbec žádný problém.

Jeden problém však způsobuje problém. Říká se mu race condition. Vlákna mohou běžet současně, jak tedy poznáme, které skončí dříve? Může se stát, že při prvním spuštění skončí první operace jako první a příště to může dopadnout naopak a druhá operace skončí dříve než první. Představte si práci s operacemi zápisu/čtení za takových podmínek! Noční můra! Někdy je velmi těžké napsat správný kód ve vícevláknovém prostředí.

Vícevláknové jazyky mají také velkou paměťovou režii, protože pro každý požadavek vytvářejí samostatné vlákno; pokud tedy chcete zavolat 1000 požadavků, vytvoří 1000 vláken.

Jak se s takovým problémem vypořádat? Použijte raději jedno vlákno! A to je to, co Uzel vám nabízí.

Jako JavaScript vývojář Doporučuji vám sledovat film
ve kterém Bart Belder jasně vysvětluje koncept smyčky událostí. Výše uvedený diagram je převzat z jeho prezentace. A pokud tyto pojmy vůbec neznáte, oba Uzel a Libuv mají vynikající dokumentaci 🙂

O blokování

Na adrese Vývoj JavaScript průmyslu říkají, že proto. Uzel je jednovláknový a neblokuje se, můžete dosáhnout vyšší souběžnosti se stejnými prostředky než u vícevláknových řešení. Je to pravda, ale není to tak krásné a snadné, jak se může zdát.

Vzhledem k tomu, že Node.js je jednovláknový (část JS), úlohy náročné na procesor zablokují všechny probíhající požadavky, dokud není daná úloha dokončena. Je tedy pravda, že v Node.js můžete zablokovat každý požadavek jen proto, že jeden z nich obsahoval blokační instrukci. Blokující kód znamená, že jeho dokončení trvá déle než několik milisekund. Nepleťte si však dlouhou dobu odezvy s blokováním. Odpověď z databáze může trvat velmi dlouho, ale neblokuje váš proces (aplikaci).

Blokovací metody se provádějí synchronně a neblokující metody se provádějí asynchronně.

Jak můžete zpomalit (nebo zablokovat) smyčku událostí?

• zranitelný regex - zranitelný regulární výraz je takový, na kterém může váš regulární výrazový engine zabírat exponenciální čas; můžete si o nich přečíst více. zde,
• Operace JSON s velkými objekty,
• pomocí synchronních rozhraní API z Uzel místo asynchronních verzí; všechny I/O metody ve standardní knihovně Node.js poskytují také své asynchronní verze,
• další programátorské chyby, jako jsou synchronní nekonečné smyčky.

Je v takovém případě možné blokovat i tato vlákna, protože Worker Pool využívá pool vláken? Bohužel ano 🙁 Uzel je založena na filozofii jedno vlákno pro mnoho klientů. Předpokládejme, že daný úkol prováděný konkrétním pracovníkem je velmi složitý a potřebuje k dokončení více času. V důsledku toho je Worker zablokován a nelze jej použít k provedení žádné jiné čekající úlohy, dokud nebudou jeho pokyny provedeny. Jak jste již pravděpodobně uhodli, může to mít vliv na výkon. Těmto problémům můžete předejít minimalizací rozdílů v časech úloh pomocí rozdělení úloh.

Závěr

Určitě se vyhněte blokování. Pokud můžete, vždy volte asynchronní verze standardních knihovních rozhraní API. V opačném případě může klient po spuštění vaší aplikace zaznamenat několik problémů, počínaje sníženou propustností a konče úplným odstoupením, což je z pohledu uživatele fatální.

Přečtěte si více:

Proč byste (pravděpodobně) měli používat Typescript

Jak nezničit projekt špatnými kódovacími postupy?

Strategie načítání dat v NextJS