Dashboard: improvements to jobs index and show pages #672
Conversation
"less than one second ago"
| @@ -8,6 +8,7 @@ module GoodJob | |||
| class Job < BaseRecord | |||
| include Filterable | |||
| include Lockable | |||
| include Reportable | |||
There was a problem hiding this comment.
Maybe a quibble, but I don't think the latency/runtime stats quite make sense for a Job record because a Job is a container for multiple Executions.
Thinking about my generic recommendations for optimizing queues, I think the number to report is the total latency for the entire job e.g. the time from when the first execution was expected to run, to the time that the job eventually finished.
There was a problem hiding this comment.
You're right. I'll remove them from the table for now, and…
I'd love to discuss what I was trying to get at by adding them: I'm looking for a snapshot of queue latency and runtime as operational metrics which indicate if there are enough workers/resources. This was just an easy way to quickly scan them to get a rough overview. It makes a lot more sense to include them on an overview dashboard rather than in the jobs list. If I remember right, resque-web had a dashboard that showed current latency for each queue.
Also, I think it makes sense for a Job to sum the queue latency and runtime for each Execution, but I'm not sure total wall clock time from start to finish is a helpful operational metric since it includes intentional backoff. Either way, this total probably only makes sense on individual job pages and an overview dashboard.
This PR includes some updates I had started working on months ago and finally got around to merging with master. It's mostly a design refresh for the jobs#index list, but includes some updates to jobs#show for consistency. There is still room for improvement here, but I think this is a good step forward.