-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic interval for batch_connect/sessions.js polling #3729
Labels
Milestone
Comments
Also worth noting that if the user has multiple tabs open with the interactive sessions page, each of the tabs will get the status of the sessions every |
Yes likely. We can cache html partials, though we don't as of yet. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The batch_connect/sessions.js polling interval is currently set to a static value via
POLL_DELAY
(link to the code), and defaults to30_000 ms
. We recently observed that the amount of httpd worker threads was running out due to a high number of users, and perhaps other causes.Either way, at this time, we noticed that the amount of sessions.js traffic was quite significant. Analyzing our logs, I can see that around 10% of our HTTP requests consist of
GET /pun/sys/dashboard/batch_connect/sessions.js?...
requests.A big factor in this is probably that users open the compute job in a new browser tab, and then the tab which is showing the app card keeps polling the
sessions.js
endpoint. This is quite unnecessary, since users presumably aren't looking at the page.I would not want to set the
POLL_DELAY
too high either, because it will affect responsiveness while users are waiting for the job to get scheduled and started.Would it be possible to dynamically adjust the
POLL_DELAY
, such that it increases substantially when the job goes into a "Running" state?For example, I could see it being useful to poll every 10 seconds while the job is queueing and starting, but then changing to 300 second polling intervals for the clients that are only looking at "Running" jobs (with a green banner).
I also notice that polling happens for cancelled or stopped jobs. This is a bit unnecessary as well, and leads to unnecessary traffic. Maybe a Refresh button could be used instead, or let the user refresh the browser page?
Let me know what you think!
The text was updated successfully, but these errors were encountered: