Last 12 weeks · 0 commits
1 of 6 standards met
I've added this dependency to a few lambda functions at global scope (outside of the itself) and it's generating some illogical readings that don't line up with latencies being tracked for total lambda execution time (or overall latency measured from the client side including round-trip). Has anyone else come across extremely large readings for lambdas? Some of the lambdas are just doing validation and then fast dynamo db reads. No CPU intensive tasks. 261 lambda invocations in an hour > 10s event loop block measurement Arguments are 50ms threshold and 50ms interval Node 20 Never seen anything like this in the 15-20 kubernetes services I've got this same dependency running in.
Want to start off by saying thank you for providing this library... while troubleshooting a main thread blocking issue in a Koa app and we systematically removed each element of the app from our server.js file only to find that the main thread will report blocked with the simplest of Node apps. With either of these code samples in node version 9.8.0: or With output: With either of the code sample above, the main thread will report blocked when the application is idle with no requests inbound to the web server and this points to a node.js internal blocking or node-blocked is misreporting blocking in certain instances. I am new to this level of internals and apologize if this is a known item. Are there false positives with node-blocked or are we potentially seeing issues within the node core internals?**
Repository: tj/node-blocked. Description: Check if the event loop is blocked Stars: 735, Forks: 34. Primary language: JavaScript. Languages: JavaScript (100%). Open PRs: 0, open issues: 2. Last activity: 6y ago. Community health: 28%. Top contributors: ensonik, tj, indatawetrust, juliangruber, lmammino, naugtur, millerick, palanik.
If threshold could be set as an option, I saw no reason why the interval couldn't be specified in the same way. Out of curiosity, is there a particular reason why the original 100 ms check interval was chosen? I can see advantages to being able to check less frequently. When you run the tests, the duration of the one that sets the interval to a strange value calls the callback at a different time than the others: