Bug 1500974 - Beaker UI cpu intensive
Summary: Beaker UI cpu intensive
Keywords:
Status: CLOSED DUPLICATE of bug 1500142
Alias: None
Product: Beaker
Classification: Retired
Component: web UI
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-11 21:27 UTC by Michael Petlan
Modified: 2017-12-06 02:45 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-12-06 02:45:28 UTC
Embargoed:


Attachments (Terms of Use)

Description Michael Petlan 2017-10-11 21:27:26 UTC
Description of problem:

When having https://beaker.engineering.redhat.com/jobs/<somenumber> opened in Firefox (52.2.0), it eats lot of CPU.

Version-Release number of selected component (if applicable):
24.4

How reproducible:
Open "My Jobs" and click on some job.

Actual results:

Firefox starts eating much CPU. Sometimes, it even shows a dialog that some script is slowing things down and whether I want to stop it or wait.

Expected results:

Beaker job page does not slow down firefox and does not eat CPU.

Additional info:

I don't know exactly which script causes that, I attempted to click on "Debug", but it didn't show anything useful. If there is any other way I can specify the problem better, let me know. For now, I just see a big difference in 'top' command and in how my fan is noisy.

Comment 1 Dan Callaghan 2017-10-11 22:21:23 UTC
Could you give an example of a job ID where this happens?

Does it happen 100% on that job, or does it occur randomly/with some other pattern?

Does this problem happen while the job is still running -- and then go away once the job is finished? In which case, it's likely caused by the 20 second polling loop for job changes. Or does it happen even when the job is already finished?

We know that there are some problems with large jobs (in the many thousands of results) which we can improve. If you are seeing the problem on a relatively small job though, then there might be something else going wrong which we aren't aware of.

Comment 2 Dan Callaghan 2017-10-11 22:22:25 UTC
Moving this bug to the Beaker product, as there is nothing to be done here at the packaging level in Fedora.

Comment 3 Michael Petlan 2017-10-16 17:20:43 UTC
(In reply to Dan Callaghan from comment #1)
> Could you give an example of a job ID where this happens?
> 
Going through my jobs, cannot reproduce it right now. Happens quite randomly.

> Does it happen 100% on that job, or does it occur randomly/with some other
> pattern?

Rather randomly, but so far jobs page.

> 
> Does this problem happen while the job is still running -- and then go away
> once the job is finished? In which case, it's likely caused by the 20 second
> polling loop for job changes. Or does it happen even when the job is already
> finished?

Not encountered on a non-running job so far.

> 
> We know that there are some problems with large jobs (in the many thousands
> of results) which we can improve. If you are seeing the problem on a
> relatively small job though, then there might be something else going wrong
> which we aren't aware of.

What exactly does a 'large job' mean? A job having a high number of recipesets or a job having any number of recipesets, but its recipesets containing too many recipes/tasks inside?

What should I do when seeing it again? I.e. firebug, etc. Can I grab more info for you somehow?

Comment 4 Dan Callaghan 2017-10-16 22:44:44 UTC
Well we know that the CPU usage of each iteration of the polling loop must be (roughly) proportional to the size of the job -- but we don't know how big the job has to be to become a problem. It is "size" in any dimension -- ultimately the page is fetching a JSON representation of the complete job (down to the level of results+logs for very task in the entire job) so the larger that JSON blob is, the more CPU time will be spent every 20 seconds on the page.

It would help the most if you could just write down job IDs where you see this problem really badly -- bad enough that it hangs your browser or interferes with your ability to use the page. That will help us to figure out exactly how big is "too big" so we can focus our optimisation efforts to make the page more usable.

Comment 6 Dan Callaghan 2017-10-23 03:19:28 UTC
I think this might actually be a dupe of bug 1500142 (effectively). Especially if the problem only appeared in Beaker 24.4.

We have discovered quite a lot of places in the UI where it is now re-rendering the HTML once per second, due to a change we made in how the page tracks the recipe watchdog countdown.

Comment 7 Dan Callaghan 2017-12-06 02:45:28 UTC

*** This bug has been marked as a duplicate of bug 1500142 ***


Note You need to log in before you can comment on or make changes to this bug.