Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Detecting Node Event Loop Blockers

ashbyhq.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Detecting Node Event Loop Blockers

#11

Post by naugtur »

Hi, blocked-at author here.

Get in touch over email if you want to explore further.

Some quick comments:

- I didn't notice the node version or you didn't state it. The impact from async hooks is _vastly_ different between node versions

- I need to update the package a bit, I've got a known perf improvement to add AFAIR.

- your implementation is likely to produce false positives. The trick to prevent (some) false positives is the most valuable part of the lib.

Also, take a look at the event loop utilization metric introduced last year https://m.youtube.com/watch?v=WetXnEPraYM&list=PL0CdgOSSGlBa...

And for more of my diagnostics experiments see debugging-aid package https://www.npmjs.com/package/debugging-aid

Re: Detecting Node Event Loop Blockers

#12

Post by naugtur »

des429 wrote: post #7

fyi to anyone seriously considering using these: neither is going to work as expected if something blocks the loop indefinitely. In other words, you won't know how long something blocked the loop until that thing has finished blocking. Timeouts for async code or limits on loop statements are still relevant.

If something is blocking the eventloop indefinitely, it's unlikely to reach production and even if it does, a simple crash report or perf inspection will reveal it. You don't need more tools than node-report for that case. Permanent eventloop block is the simple case.

Regular eventloop blocking by synchronous processing is the middle ground.

Performance issues with utilization of resources, too many promises or broken backpressure - that's where the fun begins.

If you can run your software locally and simulate load, just use node clinic. It's the best looking one ;)

Re: Detecting Node Event Loop Blockers

#13

Post by lmarcos »

When working in a green field project, does Node.js provide any advantages over, let's say, Go? In medium to big size teams, I find tricky to keep the event loop free of blockers. In this regard, Go's goroutines model make it easier to not block the whole app due to silly mistakes.

Re: Detecting Node Event Loop Blockers

#14

Post by samhw »

dgellow wrote: post #8
3pt14159 wrote: post #5

Earlier quoted context omitted.

> n'th degree of performance and memory control, don't pick Python, for instance. Or be comfortable rolling the critical parts in another language like cython, which I've done and got a 10000x performance speedup because the hot part of the code fit in the CPU cache and the rest was plain old python. There are times to start with something like Go when you're absolutely sure you'll need it, but I rarely regret starti…

You will also rarely regret starting with Go. It's not really a language you would use to have fine memory control and the best performances, so I'm not sure why you mention it as a response to the text you quoted. Go is more like a good balance between low memory usage, good performances, while being a very productive tool.

This is true. I'm a Rust fanatic myself, but I grudgingly admit that I wouldn't start a company with Rust. I just wouldn't trust future engineers enough. Whereas with Go, I'd never write it in my spare time, and I hate the paternalism and limitedness, but those same qualities make it an excellent quality for a company language.

If there's one thing I'd say about Go, it's that it's a language you can roll out across hundreds of junior engineers writing relatively sophisticated code and trust that you'll get a very respectable balance of (a) runtime performance, (b) developer productivity, and (c) safety (memory, thread[0], type, etc).

[0] OK, not in the strict way that Rust offers. But the simplicity and verbosity makes it easy to spot errors, the standard lib offers excellent primitives for concurrent programming, and `go test -race` sweeps up most of the rest.

Re: Detecting Node Event Loop Blockers

#15

Post by abhikp »

naugtur wrote: post #11

Hi, blocked-at author here. Get in touch over email if you want to explore further. Some quick comments: - I didn't notice the node version or you didn't state it. The impact from async hooks is _vastly_ different between node versions - I need to update the package a bit, I've got a known perf improvement to add AFAIR. - your implementation is likely to produce false positives. The trick to prevent (some) false posi…

Hey! We (I work at Ashby) are on latest node 16. We'll update the post to reflect that. Happy to chat over email (edit: found your email and will reach out)

Re: Detecting Node Event Loop Blockers

#16

Post by naugtur »

abhikp wrote: post #15
naugtur wrote: post #11

Hi, blocked-at author here. Get in touch over email if you want to explore further. Some quick comments: - I didn't notice the node version or you didn't state it. The impact from async hooks is _vastly_ different between node versions - I need to update the package a bit, I've got a known perf improvement to add AFAIR. - your implementation is likely to produce false positives. The trick to prevent (some) false posi…

Hey! We (I work at Ashby) are on latest node 16. We'll update the post to reflect that. Happy to chat over email (edit: found your email and will reach out)

We could break blocked-at into two layers so that you could provide the data collection mechanism. You could report to datadog while using the false positive filter.

Also, there's a bunch of tools you could use before you deploy blocked-at or async hooks at all.

Note it's midnight here and I'll stop responding very soon :D

Re: Detecting Node Event Loop Blockers

#17

Post by lmeyerov »

lmarcos wrote: post #13

When working in a green field project, does Node.js provide any advantages over, let's say, Go? In medium to big size teams, I find tricky to keep the event loop free of blockers. In this regard, Go's goroutines model make it easier to not block the whole app due to silly mistakes.

Our nodejs + python backends are all: multiple processes -> async/await nodejs/python event loops (used to be frp/streams) . It's good to solve event loop bottlenecks, but more from a individual query's latency perspective, not a machine utilization perspective: processes take care of that. Go seems great for hiring ambitious CPU coders, and Rust for ones making it safe, but the stdlib in both seem not there yet, so for most teams, the perceived increase in productivity is an illusion as it's wasted on building unnecessary things. (We actually went back to Python for web just so we can use Django, as the Node world is still too manual.)

Conversely, anything 'heavy' is probably too slow in Go/Rust too! We use GPUs for anything data-intensive, and the Python ecosystem is basically the best for that, similar to C/Java in earlier CPU eras. (I can see that changing in 2+ years as Arrow progresses and more investment happens.)

Re: Detecting Node Event Loop Blockers

#18

Post by rrgleuotyh »

lmarcos wrote: post #13

When working in a green field project, does Node.js provide any advantages over, let's say, Go? In medium to big size teams, I find tricky to keep the event loop free of blockers. In this regard, Go's goroutines model make it easier to not block the whole app due to silly mistakes.

In a small team, having the same language, libraries, and especially tooling in the frontend and the backend can be a superpower.

Other than that think it comes down to established tooling and team familiarity / preference. I do think there's no reason to start a green field Node.js project without TypeScript though.

Re: Detecting Node Event Loop Blockers

#19

Post by dgellow »

egberts1 wrote: post #10
dgellow wrote: post #8

Earlier quoted context omitted.

You will also rarely regret starting with Go. It's not really a language you would use to have fine memory control and the best performances, so I'm not sure why you mention it as a response to the text you quoted. Go is more like a good balance between low memory usage, good performances, while being a very productive tool.

Only non productive part is the endless juggling of Go modules’ versioning.

I don’t know what you mean by that. The only situation where I spent time fighting with go dependencies is when people use vanity URLs, but that has nothing to do with modules. I haven’t experienced any issue with module versioning.
Post reply on HN