Managing The Event Loop Phases ⭕️ | OPTIMIZING NODE JS
ฝัง
- เผยแพร่เมื่อ 11 ก.ย. 2024
- In this first video of my "Node JS Performance Optimizations" series, I show you how to level up you Node JS skills by managing the Event Loop phases the right way. I provide simple, yet in depth explanations and examples of how the Event Loop works as well as how to best interact with it to increase app performance.
TITLE: MANAGING THE EVENT LOOP PHASES
NOTE: This video is suitable for beginners as well as advanced Node JS practitioners.
Node JS Performance Optimizations TH-cam Playlist:
• Managing The Event Loo...
Subscribe to my Bleeding Code TH-cam Channel here:
/ @bleedingcode
Bleeding Code on Social Media
==========================
bleedingcode.com
/ bleedcode
/ bleedingcode
Hello all 👋. Question: How many of you are starting to refactor your code to make use of Promises?
There we have it. Somebody is teaching advance concept of NodeJS. WOW. Loved your tutorial. I do not usually like any videos on youtube, but yours are just WOW
Thanks so much Sanjiv. I appreciate that 🙏
To be honest I bought multiple udemy courses in order to understand the internal working of event loop but I wasn't able to grasp the phases until I found your video. I went through your channel and found that it has been 1 year since you made any video related to NodeJs. Please don't stop posting videos and continue this series.
Hi Amey. Thanks so much for that feedback. I would love to post more content like this, but it depends on what I'm working on. And right now, I'm working on a lot of Web3 stuff, but still NodeJS related, just not so performance related. But a lot can change in a short time :)
Sir I don't believe that anyone could've explained that topic the way you did, I understood pretty seamlessly
thank you ❤❤❤❤
I appreciate that very much Mostafa 🙏
This channel is gold.
Loved this “theory” of the event loop. Would be very interested in seeing the “practice” - ie, some specific non-contrived examples where replacing promises with setImmediate made a material difference (and how to recognize those cases)
Thank you Duncan. I’ve got so much content still planned but will definitely keep your suggestion in mind 👍
Man, you explain so simply and clearly! So much better for me to understand than those "Javascript Gurus" out there! I expecially like how you point things out right from the beginning.
Very good work and lots of thanks from us all !!!
Thank you for that awesome feedback 🙏
Loved it ! More contents on the inner workings of JS please ... 🙂
Thank you. Definitely more to come 👍.
Best explanation I found till now, even better than official node Js channel explanation, liked and subbed 👍🏻👍🏻
Brilliant Ravi. I'm glad I could help 👍
Thank you for explaining it in a very practical way.
I really learned event loop concept in actual way which I wanted. Thanks. keep posting more videos about how we can write non-blocking code in nodejs.
Thanks, will do :)
THE best video on the Event loop. Thank you so much!
Finally it all clicked in my head. Immense gratitude to you for your organized explanation.
Glad it was helpful!
Today I found this gem of a channel :)
Awesome thanks. I’m glad you finding these videos so valuable 👏
This is very nice, i finally get a clear picture about what is the event loop. Thankyou!
Awesome I'm glad the video helped 👏
wow superb❤❤
Thanks 🤗
Thanks for this vedio.
confusion gone, I also read doc after this.
Excellent. I'm glad you came right. Apologies for the delay in responding.
that video really really really helped me, thanks a lot, you saved me so much time, keep posting about the internals of javascript/nodejs, and keep up posting thanks
Excellent I'm glad it helped 💪
. your video is one of the fewer very interesting. cuz it deep dive in hardware...
I'm really glad it added value 👏
What a fantastic informative video. Filled with helpful information at every moment. Thank you!
You're very welcome. Thank you for the comment.
Very interesting video I ever seen for event loop
Thank you Khan. I trust it was insightful 👍
Great One. Gave a clear picture of how these phases are working. 👏👍 Expecting more on the core concepts.
Thank you Discrete Soul 🙏
Loved this one !!! Now waiting for your worker threads video series which you promised to publish before. ❤️❤️
Hahaha yes it's amazing how long it's taking. Life can sometimes really get in the way. However the scripts for the videos are now done. I've actually got 2 videos scheduled on Worker Threads.
Wow ive read that in their documentation but never really understood it. the process.tick was confusing on nodejs documentation. I just watch your video twice and I know the gist already. You need to join the nodejs foundation sir. I think they are looking for a mentor to mentee some newbies to contribute in nodejs codebase. Thank you for this!
Mr Raphael. Thank you for this awesome comment and feedback. I'll definitely be keen to help the foundation in anyway that I can. Right now I'm just trying to get my next set of videos published 😎.
Really good explanation! Thanks for sharing this content with us!
Glad you enjoyed it :) - John
This is an amazing video !!
Thank you Divyansh. I appreciate it 🙏
Nice!!! Btw loved your metal playlist 😃🎧
Haha thanks. I have not given it the attention it deserves :(
Thanks dude....waiting for more videos
Welcome 🙂. More coming soon
simply Masterclass......... thanq u
Thank you very much :)
Very helful!! I can fully understand it. Thanks
You're very welcome :)
Awesome content, thank you!! 🙏
My pleasure!
Great explanation.
Thank you very much :)
GREAT WORK
Many many thanks :)
This was great , Now I am going to watch your other videos.
Thank you very much for the compliment. I apologize in advance for some of my initial videos. That been said I'm hoping to publish new content weekly 👍.
nice crisp and to the point
thanks for this awesome video
You’re very welcome Himanshu 🙏👍
really awesome video
thanks a lot !!!!!!!!!!!!!
more videos pls :)
Thanks. More to come :)
well explained
Love you master from India
Thank you 🙏
Very useful video 👍🏻
Thank you Vasu :)
Best video so far on the Node event loop! Can you please write a very simple example here (or in a codesandbox) for an express endpoint logic that could block requests (delay the polling phase) vs a snippet that solves that same problem but doesn't block it or blocks it way less? Cheers
Hi Mátyás. Thanks for the reply and compliment 🙏. I've been asked questions similar to yours.
I have a great idea for an open src app that will demo various forms of event blocking logic and how it will affect new incoming requests. The app will then have recommended alternatives for each test that will also be measured by benchmarking tools (most likely autocannon). My goal is to have this app available on GitHub very soon, of which I will then provide video tutorials on how to use the app as well as extend it.
I might need a week or 2 to get this going, but will make it a priority 👍.
@@BleedingCode That sounds very nice! Will give you a star for sure when it's done! :D
Great content. Keep creating awesome contents.
Thanks again Tejomay. Hoping to get some more videos out soon 👍
Thanks for this clear explanation. You should keep it up
Thank you Orhan for watching. I'm glad it helped you 👍
Thanks alot man...that really helped
I'm really glad, thank you :)
Please post more videos master ..
Amazing video if u have to get in deep for eventloop
Thank you I appreciate it 🙏 - John
Super explanation, super content. Keep going! Subscribed.
Awesome thanks so much for joining 🙂
@@BleedingCode I'll much appreciate if you could help me with this:
1. In your performance tips list, you have TIP NR 3 and TIP NR 5 that are related and from what I understood it prevents blocking the EVENT LOOP by not defining each async task as a micro-task. Do you have some examples in a day to day coding activity, where we could block EVENT LOOP by not respecting those two tips?
2. From my experience with node is that almost each 3rd party dependency that you use in your app it's promised based. How this relates to TIP NR 3 and TIP NR 5.
THX and have a nice day!
@@mroobert Hi Robert. Right, so for question 1: I usually pick on bcrpt-node for slow transactions because it's written completely in NodeJS and is synchronous. Another easy way is to just create a loop that iterates a few billion times. In the real world though, what usually happens is e.g. you'll fetch data from 2 separate database servers and then loop through the data to create a single object. This could really hurt the event loop.
For question 2: For 3rd party modules that wrap their logic in promises, it's actually irrelevant and can be treated as executed immediately. If you call these promises via setTimeout and setImmediate, you will move to the next tick of event loop, thus first processing incoming requests.
I hope I helped explain things?
@@BleedingCode thx so much for your quick response. So by having these two answers in my mind and by reading some extra info, if I understood correctly:
1. It is best to keep an eye on the time complexity of the callbacks. In other words, each of your callbacks should complete quickly. As you said regexps and JSON operations are a RED flag so you should be very carefully with them.
2. setImmediate() seems to be a good choice for partitioning long-running synchronous code because it's after the Polling Phase so we don't block incoming requests. A more extreme solution is to offload potentially blocking code to a worker thread.
3. Going back to my question with "3rd party modules that wrap logic in promises", if we take mongoose that provides you communication with a MongoDb, we can see that queries to the db are wrapped with promises. And I was curious why is done like this and not with setImmediate(). As I was thinking about a code sequence where we have an endpoint "/orders" with a callback in which we query the "orders" from the MongoDb (by promise), I was ohhh... when the callback for this endpoint gets resolved, it would be best that the callback for the "orders" db query to be resolved as soon as possible and the endpoint response to be sent afterwards. This could be done by the promise because being a micro-task, the callback attached can run in any phase in which the Event loop would be found at the moment of the resolved promise.
Waiting for your feedback on these one:D. Thx so much for your time! All the best to you!
Very helpful Content! Liked and Subscribed! Why don't you post videos more often?
Thanks so much for the feedback. Honestly it comes down to what pays the bills right now takes priority, and my current responsibilities are taking up all my time :(. I hope to have things change in the near future.
Pretty good,thanks.
You’re welcome. Thanks for watching 👍
You are the best
Thank you Hazem 🙂.
Great video full of valuable information! I also love your accent ahah.
Do you have the code used in the video published anywhere? I would like to try it myself
João. Firstly, kudos on the name 👍. As I'm sure you've guessed from my last name my name is also João (from Portuguese descent), but here in South Africa it's a bit too complex, so I resort to John.
Secondly, thank you for the compliment. I really appreciate it. Regarding the source code, gimme a day and I'll send it up to GitHub and will reply to your message with a link.
Cheers 😎
@@BleedingCode Oh wow, I didnt know that! Thank you so much!
Thank you so much sir.
You're most welcome Mayur 🙂
great video
Great video!
I have questions regarding the second phase,
The name "I/O Logic" is the parallel name for "Pending Callbacks" in NodeJs docs?
if yes then:
You said callback function of fs, network, encryption, etc. will run in this phase but according to NodeJs docs, they will run in the third phase.
NodeJs docs:
"pending callbacks: executes I/O callbacks deferred to the next loop iteration."
"poll: retrieve new I/O events; execute I/O related callbacks (almost all with the exception of close callbacks, the ones scheduled by timers, and setImmediate()); node will block here when appropriate."
So what is the right behavior? fs callbacks will run in the second phase or third phase?
Hi Dan. Thanks for the feedback and for watching.
Yes phase 2 and 3 are very misleading and the NodeJS docs don't really help much. From my experience phase 2 and 3 perform mostly the same operations, except that Phase 2 handles I/O related callbacks that were put off/postponed for the next event loop cycle before moving to Phase 3. I need to turn this into a discussion on its own, but truthfully I need to find better information on these 2 phases. Right now most articles written on these phases conflict badly with each other.
@@BleedingCode Thank you for your comment,
Like you I was confused by the articles.
I have an assumption, in windows callbacks will run in phase 2 and in linux/unix they will run in phase 3
10/10
Thank you 🙏
console.log() is not synchronous inside a worker thread. And messages sent to console from the worker thread can be lost if app exits.
This is valuable insight thanks for sharing.
Regarding point 5. at the end of the video, to prioritize polling phase, is it best to just use setImmediate()? I have seen setTimeout(0) being used for that but doesn't that mean we might go straight back to executing the callback without getting to polling phase?
Yes setImmediate() is better if you want to execute the logic the moment the loop reaches the next iteration. Most people use setTimeout() either because they want to wait x milliseconds before the code executes, or because they don't realise that setImmediate() is an option.
@@BleedingCode Got it, thanks for the answer.
thanks a lot !!!!!!!!!!!!!!!!!!!!😊🙏🙏🙏🙏🙏❤️💕
Always a pleasure 👍🙂
Appreciate your video. Still have a few related questions:
1. What about async ES imports? Are they handled as I/O and result is wrapped in Promise, so as microtask after that I/O or are they some kind more specific?
2. And pretty similar, what about I/O that is also promisified? Will be there any difference in using a callback or promisified version? Or it will be just execution of Promise microtask after I/O phase and no difference in timings?
Great questions Bohdan. I need to check a few things regarding on point 1 and will respond asap 👍
@@BleedingCode any updates on that?
@@bohdanlukashchuk9893 Hi Bohdan. Apologies for not replying sooner. Static ES Imports are synchronous and are loaded at the root of the app upon startup. Dynamic imports, as you have already stated, are wrapped in a promise and can be lazy loaded when required. What I haven't been able to confirm is if there's more async operations happening or if it's just a Promise Microtask. You can however answer that question using Async Hooks. Check my video on how to achieve this: - th-cam.com/video/yiBLmRRRx-k/w-d-xo.html
@@BleedingCode thank you, was full of work, will check that video. You are doing great work!
@@bohdanlukashchuk9893 Thanks again Bohdan 🙏
the above code where you tried calling settimeout and setimmediate inside the second settimeout, so my question is that did event loop check those two functions in second cycle?
Correct. In the setTimeout phase.
Why did you say console.log() is synchronous at 18:40? according to node.js documentation it's a wrapper for "process.stdout.write()" which is inherently non-blocking.
To emphasize to importance, if you have a process it can exit before executing console.log(), which can be sometimes unintended, but if you want to make sure whatever you want to log is logged you would use console.error() or console.warn() for example, because they are blocking and the process will wait until they are executed before exiting.
src: nodejs.org/en/knowledge/getting-started/the-process-module/
also, I've noticed the Libuv mentioned around 7 phases, are they omitted in this video for a reason?
src: docs.libuv.org/en/v1.x/design.html
thanks for the effort
Hi Ariel. Thanks for posting. To answer your first question...console.log triggers a number of processes, 3 of which are asynchronous. However, depending on certain scenarios, sync tasks are also triggered, especially on posix operating systems - nodejs.org/api/process.html#process_a_note_on_process_i_o
To answer your 2nd question, I omitted the other phases because, as per my understanding, they are used internally by libuv and cannot be managed by one’s operations. I would love to know if I’m mistaken about this. Cheers.
Hi Bleeding Code I've been watching all your Nodejs videos which are really good.
In your diagram of the event loop you mention Promises are executed at each stage along with process.nextTick(). I don't see that written in the Node documentation at all.
Also I have run some tests, and no matter how I set up my code, the promises are always executed after setTimeout and setImmediate, so I'm not sure that promises are executed in the way you say. If you have a source for this I am very happy to be corrected.
Hi Kane. Thanks for your reply. Here's a link to the source code of the demo I used in the video - github.com/bleedingcode/nodejs-performance-optimizations/tree/master/01-testing-event-loop-phases
If I am using await a lot in axios operation, then is it blocking the event loop? Is there any other way to speed it up given that I have to use all those calls in sync
Hi there. So, even though you're using await with Axios...the HTTP request itself is non-blocking, because it gets handed off to the OS. It's only when you're using await on userland code, that it will essentially block the event loop because it's a "Promise" microtask.
@@BleedingCode ah thanks, btw what's userland code? Any example? Also tasks handled by OS are non blocking is it ?
@@inclinedscorpio Hi there. Userland code is your actual code/logic that you write in JavaScript. It's common term and you can easily google it for more info. Yes, tasks handled by the OS are asynchronous, or are managed by the libuv threadpool. Check out my Playlist on TH-cam as I discuss this in a different video :)
@@BleedingCode Definitely will check.
Thanks for making all these wonderful videos man. Respect++
@@inclinedscorpio Always a pleasure
can you add breif description regarding the async require
Hi Hamza. Sorry for the late reply. That's a good point. I need to maybe provide a video on how and where async require fits into the scheme of things. The truth is I don't know off hand and don't want to provide partially correct into.
I am a little confused here.
At 4:41 you said setTimeout & setInterval are handled in phase 1. But then later (at 20:30), you say - always prefer setTimeouts over setInterval because they are handled in phase 4.
Hmm apologies. Can you help pinpoint where In the video I contradict myself that so I can explain what I meant?
@@BleedingCode Sorry. I have updated my comment and added another timestamp
@AdityaFingerstyle Thanks for updating your comment. I’ve reviewed the video around 20:30 and I think I understand your confusion. 2 points regarding this:
1. You mention that I’m telling one to always prefer setTimeout over setInterval. I checked the video and I don’t mention setInterval at that time? That been said, the reason I mention setTimeout and not setInterval is because setInterval serves a different purpose in that it’s a re-occurring async function. You would only ever use it for logic that needs to be executed continuously vs once off.
2. Then, the confusion about Phase 4: I see where you got confused. I vocally state that setTimeout and setImmediate happen after the polling phase, but in the video I highlight Phase 4 whilst stating that, making it look as if both setTimeout and setImmediate happen in Phase 4. My apologies for that. What I meant is that setImmediate would occur after the polling phase because it’s in Phase 4, and that setTimeout will occur after the polling phase because it would only get executed in Phase 1 in the *next Cycle/Tick*.
I really hope that makes more sense. Please let me know if I need to explain it further 👍🙂.
@@BleedingCode
1. I understand that they serve different purpose. I was more concerned about their precedence in the event loop.
2. That clears it up. Thank you
const to = 0;
const main = () => {
setTimeout(()=>{
console.log("0 timeout");
},to);
setImmediate(()=>{
console.log("immediate");
});
};
everytime i ran. immediate came first. Can anyone give example where setTimeout comes first before setImmediate? looks like eventloop starts from polling phase
Hi there. Sorry for the late reply. If you reference my video around 10 minutes in, you'll notice I explain a weird situation that occurs on load of the app. Is this not what's also happening to you? - 10:12
Hello there!
First i wanna thank you for this great video and explanations, very good job :)
Now, i gotta say i'm a bit confused about what's going on during phase 2.
What is the difference between I/O callbacks that get executed on phase 2 and those on phase 3? Both are I/O callbacks
(the official docs explanation did not help me to really understand it).
Hi Roy. Thanks firstly for watching and for your feedback 🙏.
Yes phase 2 and 3 are very misleading and the NodeJS docs don't really help. The truth is phase 2 and 3 are actually the same, except that Phase 2 handles I/O related callbacks that were put off/postponed for the next event loop cycle.
@@BleedingCode And where do they get postponed? On phase 3?
@@royinchains Yes that's correct. What I can't guarantee is what method was used to defer the callback. I know it's not nextTick, setImmediate or setTimeout.
@@BleedingCode Interesting.
Thank you very much 🙏
is there any events that we can subscribe to the phases mentioned?
Sorry for the late reply. Off the bat I'm not sure, but I need to update these tutorials and will keep this in mind.
In which phase eventEmitter works?
Good day Gourav. I am nervous answering this question because I don't usually work with Event Emitters. However, as I understand it, natively it's synchronous logic. It's only when you apply asynchronous functions on the handlers that they become async, and in that case the phase it will be triggered is dependent on the async function you used.
in which phase the thread pool will be executed ?
Hi Hazem. If I understand your question correctly, transactions handed off to the OS can occur in any phase, but responses, will be managed in Phase 2. Whether these transactions get handed over to the Libuv Threadpool depends on if they're natively asynchronous or not. I recommend checking out my video - "INCREASE NODE JS PERFORMANCE WITH THREAD POOL MANAGEMENT" - th-cam.com/video/LC5FC3FdzAE/w-d-xo.html, where I explain the Libuv Threadpool in more detail.
I hope this helps.