Goal
Deliver metadata around pool performance using diagnostics_channel
Proposal
Instead of directly accessing pool performance metadata from Piscina#<histogram|utilization> provide it as a diagnostics_channel event that decouples this from the actual Piscina implementation, enabling data fetch through a more performance channel.
dc.subscribe('piscina:task:done`, evt => {
console.log(evt.duration);
console.log(evt.taskId);
console.log(evt.poolName); // To be able to identify multiple pools in case more than one is running
console.log(evt.queueSize); // size of the queue at the moment the task is done
console.log(evt.idleThreads); // number of idle threads at the moment of the task marked as done
})
// `piscina:task:submit` <- when I task is about to be submitted
// `piscina:task:done` <- when a task is marked as done
// `piscina:pool:new_worker` <- when the pool has triggered the drain event
// `piscina:pool:evict_worker` <- when the pool has triggered the drain event
// `piscina:pool:drain` <- when the pool has triggered the drain event
Notes
- Some of the events can be dropped, are just suggestions.
- The histogram will still live as part of the pool instance.
Goal
Deliver metadata around pool performance using
diagnostics_channelProposal
Instead of directly accessing pool performance metadata from
Piscina#<histogram|utilization>provide it as adiagnostics_channelevent that decouples this from the actual Piscina implementation, enabling data fetch through a more performance channel.Notes