event loop თქვენს JavaScript-ს ასრულებს ერთ ნაკადზე (thread), ამიტომ ნებისმიერი სინქრონული რამ, რაც დიდ დროს მოითხოვს, ბლოკავს მას — და ბლოკირების დროს Node არ ემსახურება არცერთ სხვა მოთხოვნას, ტაიმერს ან callback-ს. ბლოკირება თითქმის ყოველთვის CPU-ზე დამოკიდებული სამუშაოა ან *Sync API, არასოდეს სწორად await-ირებული ასინქრონული I/O.
*Sync) API-ები — fs.readFileSync, fs.writeFileSync, child_process.execSync, zlib.gzipSync. ისინი ადგილზე ელოდებიან, ნაცვლად იმისა, რომ libuv-ს გადასცენ.map/sort/filter, მატრიცული მათემატიკა, სურათის/ვიდეოს დამუშავება, უზარმაზარი სტრუქტურების parsing/serializing.JSON.parse / JSON.stringify — სინქრონული და O(n); რამდენიმე MB-იანი payload აყინავს loop-ს მთელი parse-ის განმავლობაში.crypto.pbkdf2Sync, bcrypt sync რეჟიმი, დიდი ბუფერების ჰეშირება მთავარ ნაკადზე.while (true), შეუზღუდავი რეკურსია, for მილიონობით ელემენტზე თითო ელემენტზე სამუშაოთი.// ეს ყველა ბლოკავს loop-ს — ამ დროს არცერთი სხვა მოთხოვნა არ მუშავდება:
const data = fs.readFileSync("big.json"); // სინქრონული I/O
const obj = JSON.parse(hugeString); // დიდი parse
const hash = crypto.pbkdf2Sync(pw, salt, 1e6, 64, "sha512"); // სინქრონული crypto
for (let i = 0; i < 1e9; i++) { /* CPU */ } // მჭიდრო ციკლი
CPU სამუშაოს
asyncფუნქციაში გახვევა არ ეხმარება —asyncმართვას გადასცემს მხოლოდawait-ზე; სინქრონული სხეული მაინც ბოლომდე სრულდება loop-ის ნაკადზე.
perf_hooks.monitorEventLoopDelay()-ით ან ბიბლიოთეკებით, როგორიცაა blocked-at; მზარდი lag ნიშნავს, რომ რაღაც იკავებს ნაკადს.node --prof, clinic doctor/clinic flame, Chrome DevTools-ის CPU პროფაილი ცხელი სინქრონული frame-ის საპოვნელად.*Sync გამოძახების ასინქრონული ანალოგი (fs.promises.readFile, crypto.pbkdf2, zlib.gzip).worker_threads pool-ში, child process-ში, ან გარე queue-ში/სერვისში.setImmediate/await-ით, რომ loop-მა შეძლოს სუნთქვა batch-ებს შორის.const { Worker } = require("node:worker_threads");
// გადმოიტანეთ ძვირი hash, რომ loop დარჩეს რეაქტიული.
const worker = new Worker("./hash-worker.js", { workerData: { pw, salt } });
Node-ში ერთი ბლოკირებადი გამოძახება სჯის ყველა ერთდროულ კლიენტს, არა მხოლოდ იმ მოთხოვნას, რომელმაც ის გამოიწვია — latency იზრდება, health check-ები timeout-ს აკეთებენ და პროცესი დატვირთვის ქვეშ „ჩამოკიდებულად“ გამოიყურება. ინტერვიუერები ამას სვამენ იმის დასანახად, შეგიძლიათ თუ არა კონკრეტული ბლოკერების დასახელება (*Sync, დიდი JSON.parse, სინქრონული crypto, ReDoS, CPU ციკლები), მათი ამოცნობა event-loop-lag ინსტრუმენტებით და გასწორება ასინქრონულზე გადასვლით ან worker thread-ებზე გადატანით. ეს არის Node-ის ყველაზე გავრცელებული წარმადობის ხარვეზი production-ში.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა