Pętla zdarzeń uruchamia twój JavaScript w jednym wątku, więc wszystko, co jest synchroniczne i trwa długo, blokuje ją — a podczas blokady Node nie obsługuje żadnego innego żądania, timera ani callbacka. Blokowanie to niemal zawsze praca ograniczona przez CPU lub API *Sync, nigdy poprawnie awaitowane asynchroniczne I/O.
*Sync) — fs.readFileSync, fs.writeFileSync, child_process.execSync, zlib.gzipSync. Czekają w miejscu, zamiast oddać pracę do libuv.map/sort/filter na tablicach, matematyka macierzowa, przetwarzanie obrazu/wideo, parsowanie/serializacja ogromnych struktur.JSON.parse / JSON.stringify — synchroniczne i O(n); ładunek wielomegabajtowy zamraża pętlę na cały czas parsowania.crypto.pbkdf2Sync, tryb sync bcrypt, haszowanie dużych buforów w głównym wątku.while (true), nieograniczona rekurencja, for po milionach elementów z pracą na każdy element.// Wszystkie te operacje blokują pętlę — w tym czasie żadne inne żądanie nie jest obsługiwane:
const data = fs.readFileSync("big.json"); // synchroniczne I/O
const obj = JSON.parse(hugeString); // duże parsowanie
const hash = crypto.pbkdf2Sync(pw, salt, 1e6, 64, "sha512"); // synchroniczne crypto
for (let i = 0; i < 1e9; i++) { /* CPU */ } // ciasna pętla
Opakowanie pracy CPU w funkcję
asyncnie pomaga —asyncoddaje sterowanie tylko przyawait; synchroniczne ciało i tak wykonuje się do końca w wątku pętli.
perf_hooks.monitorEventLoopDelay() lub bibliotek takich jak blocked-at; rosnące opóźnienie oznacza, że coś zajmuje wątek.node --prof, clinic doctor/clinic flame, profil CPU w Chrome DevTools, aby znaleźć gorącą synchroniczną ramkę.*Sync (fs.promises.readFile, crypto.pbkdf2, zlib.gzip).worker_threads, procesu potomnego lub zewnętrznej kolejki/usługi.setImmediate/await, aby pętla mogła oddychać między partiami.const { Worker } = require("node:worker_threads");
// Odciąż kosztowne haszowanie, aby pętla pozostała responsywna.
const worker = new Worker("./hash-worker.js", { workerData: { pw, salt } });
W Node jedno blokujące wywołanie karze każdego równoczesnego klienta, a nie tylko żądanie, które je spowodowało — skoki opóźnień, przekroczenia limitu czasu health checków, a proces wygląda na „zawieszony" pod obciążeniem. Rekruterzy pytają o to, aby sprawdzić, czy potrafisz wymienić konkretne blokery (*Sync, duże JSON.parse, synchroniczne crypto, ReDoS, pętle CPU), wykryć je narzędziami do pomiaru opóźnienia pętli zdarzeń i naprawić je, przechodząc na async lub odciążając do wątków roboczych. To najczęstsza awaria wydajności Node w produkcji.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj