action #55112
closed
Load dashboard contents on demand
Added by mkittler over 5 years ago.
Updated about 5 years ago.
Category:
Feature requests
Description
The loading time of the openQA start page is quite slow. This is because accumulating all the displayed build results involves a lot of database access and processing data with Perl code.
An idea to improve this is loading these dashboard contents only on demand. This make sense because for a lot of use cases the start page is just used to navigate to another page or to login. I would add a button to load the dashboard contents via AJAX and also a query parameter to trigger this automatically (so if someone wants to save the click after all one can add a bookmark).
Files
I've just did a quick benchmark and the build results are what the main page slows down mostly, indeed. The seconds thing is already the job groups menu bar but compared with the build results this is not significant.
Note that just out-commenting code in the template (like @okurz tried to test the performance improvement in production) does not help to see the difference because compute_build_results is nevertheless executed.
I disagree with 'on demand' - I consider it a vague theory that people go to that page to jump to the menu. I would on the opposite think people go there to click into the build results.
The problem with the / route is more that it's polled so often by monitoring plugins - we disabled 2/3 of them by now. What would be interesting to know: can we split the calculating of the job groups from the exact job details loaded by AJAX? That would make plugins polling / less problematic, as they wouldn't query the expensive function - offer a quick link to job groups for those navigating, but still offers the dashboard for those needing it.
- Category set to Feature requests
btw, Engineering Infrastructure has moved from / to /tests now in #55691
I thought of loading build results asynchronously but still automatically so that anyone moving on to job groups or /tests or the user menu can already go the next step without needing to wait 30s
coolo wrote:
[…] can we split the calculating of the job groups from the exact job details loaded by AJAX?
you mean making sure to only evaluate the result of each job so that we can compute the bars? I doubt we have anything to optimize in this regard. We also already prefetch comments and such.
- Category deleted (
Feature requests)
can we split the calculating of the job groups from the exact job details loaded by AJAX?
Not exactly sure what you mean. But we can of course simply load the entire contents beyond the branding box via AJAX. That would be like the dashboard on GitHub and technically similar to what I proposed before just without an extra click.
- Category set to Feature requests
- Priority changed from Normal to Low
- Status changed from New to In Progress
- Assignee set to mkittler
- Target version set to Current Sprint
- Status changed from In Progress to Resolved
- Target version changed from Current Sprint to Done
I saw it working in production on o3 however with a tiny problem. When I click on another link while the build results are showing for a short moment a red error box shows up that the build results could not be rendered, as the request was canceled by wanting to go to another target in the meantime. See 
To reproduce: Go to https://openqa.opensuse.org/ , while the page loads, click on "All tests", observe the error message before the browser switches to /tests. I suggest to handle that request cancel gracefully, e.g. do not show the error when a request for another page is pending. Not sure if this needs all to be handled in javascript, I assume so.
fvogt mentioned another problem. The text with relative time, e.g. "3 days ago" disappeared. It just shows the timestamp, not nicely formatted.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF