Threadpool monitoring / metrics

[davisjam]

Is your feature request related to a problem? Please describe.

My (hypothetical) application uses the threadpool. Is the work performed in the threadpool the bottleneck for my application performance? This is hard to know at the moment.

Describe the solution you'd like

I would like API(s) to monitor the state of the threadpool.

Describe alternatives you've considered

Since the threadpool is currently embedded in libuv without monitoring hooks (but see libuv #1528), monitoring is not easy to do.

I think a monitoring API would be a logical thing to include within or following #22631.

I would like community input on what the API should look like and what metrics people would find valuable.

[jasnell]

See: libuv/libuv#1815

[Trott]

@davisjam Is this still something you'd like to discuss? Or is this something that should likely be closed at this point?

[jasnell]

@trevnorris is working on a pr to libuv that would add a critical metric and the mechanism to add more. Once that lands I think this is something we could move forward on

[davisjam]

@Trott

I think it's still a valuable feature for Node. I am planning to direct some students towards these questions in the fall.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.