Let’s implement it because I’m sure it will help you gain a deeper understanding (and because it would make for a nice exercise in a coding interview □)Īs we can tell from the output some loop iterations exhibit minimal lag and others suffer from massive lag. Of course we could just install a package from npm to do it for us or use the official monitorEventLoopDelay but where’s the fun in that? Now that we got the theory covered let’s find out how to measure event loop lag. The longer an iteration takes the more synchronous work is done and the slower the application becomes. So by measuring the time between scheduling and execution we actually measure how much time our own code consumes in a single event loop iteration (roughly). When I say “code squeezed in between” what I actually mean is “your own synchronous code”. What exactly happens in the time between the scheduling of a callback with, say setTimeout(fn, 0), and the execution of fn? Well, the event loop proceeds its current iteration until it reaches the next timer phase and runs any code that happen to be squeezed in between (the blue circle in the image above). The blue circle indicates the time span until it is executed. Or, since a picture says more than a thousand words:Īn example where a timer callback is scheduled in the ‘poll’ phase. What is event loop lag?Įvent loop lag measures the time span between the scheduling of a callback and its execution If you’re unsure the official docs do a pretty good job at explaining everything you need to know to follow this article. Since you’ve made it until this point I’m assuming that you know the basics of Node.js, its single threaded nature and that you understand what setTimeout does. Note: For this article, a basic understanding of how the Node.js event loop works is required. With this in mind you might be wondering: wouldn’t it be great to have a continuous measure for synchronous work? A concrete numeric value that you can plot in a line chart? A metric based on which we can trigger an alert once it reaches a threshold? Luckily, that metric exists: It’s called event loop lag. Furthermore, profiling is usually what you do once the damage is done and it’s too late. While profiling is indeed a great way to find the needle in the haystack I would argue that it should be the last resort as the process is difficult and time consuming. One advice that many Node.js devs would give you in this situation is to start profiling and flame graphing your app. You only realize that something is fishy when your application’s performance starts degrading. The problem is that typically, you don’t know if there is synchronous code in your application. So I guess we can agree that synchronous = bad. And as a result:Įvery second your code does synchronous work is a second you add to your web server’s response time. In a web server scenario this would mean that as long as the thread is busy you would not be able to react to any incoming requests. If you keep that single thread busy with long running operations you prevent it from doing anything else. Why is synchronous work bad? Because in Node.js, there is only a single thread. If you ask any Node.js developer for their number one performance tip, chances are close to a hundred percent that they will give you the following advice: Monitoring Node.js: Watch Your Event Loop Lag!Įvent loop lag is an essential, but often overlooked performance metric for Node.js applications.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |