track last activity of kernels

[minrk]

It's proven useful in JupyterHub to track last activity on each notebook server and expose that on the API, so that external services can perform operations such as culling idle servers, etc. We could track similar information on a per-kernel basis in the single-user notebook.

Rough draft in my head:

• subscribe a single activity monitor SUB socket to all kernels' IOPub channels
• primitive version: update last_activity on each message, not bothering to deserialize
• cleverer version: use busy/idle, so that a silent but busy kernel doesn't appear as idle
• include last_activity timestamps in the models on the kernels (and thereby sessions) REST API

[takluyver]

I think that's a good idea.

Should the value in the model be a last_activity timestamp or an idle time? Thinking about the smarter version with busy/idle checking: if it's currently busy, idle time is zero, whereas calculating a 'now' timestamp is a bit more work and less immediately clear for someone inspecting the protocol.

[dsblank]

Could this be used for educators looking at things like "Time on Task"?

What could be useful from logs would be information like:

• each time that a particular cell was executed
• idle time
• time spent editing a particular cell (perhaps through indirect measures)

[ellisonbg]

It think it is a good idea to have something like this. Not sure it is
worth the cost of deserializing all the messages thought to handle the
busy/idle stuff.

On Tue, Mar 22, 2016 at 8:22 AM, Doug Blank [email protected]
wrote:

Could this be used for educators looking at things like "Time on Task"?

What could be useful from logs would be information like:

• each time that a particular cell was executed
• idle time
• time spent editing a particular cell (perhaps through indirect
  measures)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1241 (comment)

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[minrk]

@dsblank this wouldn't be useful for something like that, because it has no awareness of the document. That would probably be better written as a javascript extension.

[minrk]

Forgot to close this in #1827