Don't forget that the main event loop in Node can still get backlogged. This can result in skipping garbage collection which can appear like a memory leak and even shut everything down if you're not careful. So while you can federate out the work, the central thread can still get bogged down.
My main expertise is Java and all Java related but now I do Node.js and TypeScript on backend. I’m 37 and I’ve got a wife a daughter and big ass 4WD that I use to tour Australian Outback.
Education
In mysterious Russia. I’m actually a rail road electrical automation engineer by trade.
I mean, there are many folks that would argue with that. Example
I will freely admit that I don't know these intricacies well, especially since this came from a debugging session for work many years ago for a crypto service written in JS/Node. It received so many requests that it appeared garbage collection could not run reliably and that it appeared like we had a memory leak when we did not. We had several devs look at it during this time as it was high profile, and that was the conclusion we came to, and our monitoring support it.
My main expertise is Java and all Java related but now I do Node.js and TypeScript on backend. I’m 37 and I’ve got a wife a daughter and big ass 4WD that I use to tour Australian Outback.
Education
In mysterious Russia. I’m actually a rail road electrical automation engineer by trade.
This is the key, than means that the stage of libvuv event loop that calls handlers (C level handlers that is) was running all of them and there were so many, that the event loop didn’t progress to further stages.
I didn’t dig further into when node is triggering GC. Would be interesting to see if GC is tied to certain stages.
My main expertise is Java and all Java related but now I do Node.js and TypeScript on backend. I’m 37 and I’ve got a wife a daughter and big ass 4WD that I use to tour Australian Outback.
Education
In mysterious Russia. I’m actually a rail road electrical automation engineer by trade.
Great article!
The only nuance is that diagrams look like libuv call into V8 directly, which is not the case. Node sets up the handlers and those handlers prepare stack and state for V8 to run and then run V8.
The reason this is important is because a lot of people have a notion of having V8 run continuously which is not the case. We enter there and exit from there though Node’s handlers for various libuv stages.
Your favorite Full Stack Web Developer, I can build anything magically 🔮🪄 for you with React, NodeJS and Firebase 💻🧑💻, and I can put my beautiful UI & UX skills to your app 🎨🖌️.
Don't forget that the main event loop in Node can still get backlogged. This can result in skipping garbage collection which can appear like a memory leak and even shut everything down if you're not careful. So while you can federate out the work, the central thread can still get bogged down.
There’s no “main event loop” in Node. There’s default event loop in libuv.
I mean, there are many folks that would argue with that. Example
I will freely admit that I don't know these intricacies well, especially since this came from a debugging session for work many years ago for a crypto service written in JS/Node. It received so many requests that it appeared garbage collection could not run reliably and that it appeared like we had a memory leak when we did not. We had several devs look at it during this time as it was high profile, and that was the conclusion we came to, and our monitoring support it.
“It received so many requests”.
This is the key, than means that the stage of libvuv event loop that calls handlers (C level handlers that is) was running all of them and there were so many, that the event loop didn’t progress to further stages.
I didn’t dig further into when node is triggering GC. Would be interesting to see if GC is tied to certain stages.
Great article!
The only nuance is that diagrams look like libuv call into V8 directly, which is not the case. Node sets up the handlers and those handlers prepare stack and state for V8 to run and then run V8.
The reason this is important is because a lot of people have a notion of having V8 run continuously which is not the case. We enter there and exit from there though Node’s handlers for various libuv stages.
It would be worth to mention that UV_THREADPOOL_SIZE is actually limited for extention by your CPU logic threads amount.
That's a good one, thanks!
That about Bun?
It feels like nodejs is completely superseded by Bun,
at least it has in all of my use cases.
Wow, great article. Thank you for sharing!
It is a good thing we have threads now so that node can be a little more versatile when cpu intensive tasks are needed, great writeup Tkachenko :)
Amazing article, also if we have CPU extensive tasks to do, then we can simply run them with C++ as NodeJS is very well integrated with C++