Add duration property to completed jobs
See original GitHub issueIt would be nice if jobs would track how long they took to execute. If they already do, that’s great, but it wasn’t obvious from the docs or the properties on the job object how they do that.
Suggestion:
//Track high res start time
const startTime = process.hrtime();
//Run job handler
//...do stuff...
//Track high res end time
const endTime = process.hrtime();
//Get duration in MS
const ms = (end[0] - start[0]) * 1e3 + (end[1] - start[1]) * 1e-6;
//Store on completed job
job.duration = ms;
Currently doing this manually, but it would be nice if this was implemented in bullmq internally.
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Change a task duration - Microsoft Support
Change a task duration at any time by using the Duration column. You can also change the duration unit from days to hours,...
Read more >Job Properties - Documentation for Control-M Automation API ...
Job Properties. Below is a list of job properties for Control-M objects. ... You can add or remove events from the Control-M by...
Read more >Adding jobs in AWS Glue
AWS Glue triggers can start jobs based on a schedule or event, or on demand. You can monitor job runs to understand runtime...
Read more >Understanding Task Properties - SkedPal
To schedule a task, you'll need to estimate the time needed to complete the task. The duration chip in the line (task) detail...
Read more >`.gitlab-ci.yml` keyword reference - GitLab Docs
A blocked pipeline does not run any jobs in later stages until the manual job is started and completes successfully.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

but of course we could add a new sets of properties ending in hr for the high resolution version like onProcessedHr, etc.
Yes that would be great. Personally I would also rename the properties to be a bit clearer, as it’s quite confusing if you don’t know BullMQ well. E.g.
startedOn,completedOnis clear just from reading it, whereasprocessedOncould be interpreted in different ways. I realise this would be a breaking change though.