Add metadata to show how long certain jobs have been running

[Pshepp]

Is your feature request related to a problem? Please describe.
When trying to get some more granular behavior regarding a specific bug, I was hoping to get how long a couple of functionalities (i.e. tip5p minimization) have been waiting to run, how long they have been running, how long it took for them to start running, and how long the completed jobs took.

Describe the solution you'd like
On "interesting" functionalities where the site waits to run some specific calculations, and running the calculations can be somewhat substantial or we have to wait sometime to run said calculations, it would help if we were able to track the following in order to have a better view of the landscape to better pinpoint bugs

• Time the job has been waiting to run
• Time the job has been running
• Time the job waited to run
• Time the job took to run

Describe alternatives you've considered
None really

[danwentworthart]

Question is, would this logic serve us better in:
GEMS?
Website? (Server or client?)
Both? - Some time does pass between server and client. Both may be a good answer here. Users who bypass the website may still be interested.

[Pshepp]

My bad, misclicked and will respond after I reopen this ticket lol 🐒

[Pshepp]

Hmmm that is a good question; having both would be nice because it could help us track down bad behavior more easily. For instance if we have a timer for Server communicating with GEMs , and GEMs communicating with Some Cool Tool this would let us have a better idea of where we are experiencing a failure/hang in the stack. Having another data point to track the health of some parts in our whole logic pipeline would be useful for debugging.

I could see people who directly use our API wanting to get some type of statistics for how long their request took. The big thing we must realize is the browser's console output is already pretty busy, so it will probably be good to allow for different levels of how verbose our returned timers are.

[Lachele]

I would make it part of the status reporting in GEMS. GEMS would return a JSON object with info that the website could display. We have draft code to handle this functionality for anything that has been submitted to Slurm. This is definitely planned functionality. It will definitely need to be implemented with MDaaS, so that will be soon.

…

On Tue, Nov 22, 2022 at 9:59 PM Pshepp ***@***.***> wrote: Hmmm that is a good question; having both would be nice because it could help us track down bad behavior more easily. For instance if we have a timer for Server communicating with GEMs , and GEMs communicating with Some Cool Tool this would let us have a better idea of where we are experiencing a failure/hang in the stack. Having another data point to track the health of some parts in our whole logic pipeline would be useful for debugging. I could see people who directly use our API wanting to get some type of statistics for how long their request took. The big thing we must realize is the browser's console output is already pretty busy, so it will probably be good to allow for different levels of how verbose our returned timers are. — Reply to this email directly, view it on GitHub <#107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCV7D2XWZOWJJXV4BNEROTWJWCBZANCNFSM6AAAAAASFGTMEY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- :-) Lachele ***@***.*** lachelefoley.com I'm happy people are learning that sleep is important. Now, please stop trying to kill the nocturnal folks.

[danwentworthart]

Agree with both the feature idea and where it belongs.

[Pshepp]

🙏 sounds good, ty. If there are any other links in between parts of our codebase where one side can perpetually hang (or the job can take a bit to finish) it would be nice to include the time there also. Unsure if I am preaching to the choir right now lol.

Being able to chuck the times on the front end would be sweet, if I used a site that had the timing breakdowns on the files I have been running jobs I would be happily surprised.

[cexum]

This service will be provided by the Status GEMS module.

[Pshepp]

i am p sure @GRAYgoose124 is gonna work on the status module a bit in the future, correct me if i am wrong tho so it may be good for @cexum to help him out a bit with the status module on the side as long as time permits. Up to yall tho 👹