Bug 457843

Summary: Very slow JavaScript while using query form
Product: [Community] Bugzilla Reporter: Christopher Beland <beland>
Component: Query/Bug ListAssignee: PnT DevOps Devs <hss-ied-bugs>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.2CC: ametedinov, andy, atodorov, covex, dkl, gilboad, jap, jlaska, kbaker, LpSolit
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 479725 (view as bug list) Environment:
Last Closed: 2009-01-12 03:12:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 474289    

Description Christopher Beland 2008-08-04 22:22:32 UTC
While viewing https://bugzilla.redhat.com/query.cgi, choosing a "Classification" can cause my CPU usage to go to 100% for dozens of seconds, causing annoying delays when checking to see if a bug has already been reported.  Sometimes Firefox pops up a dialog box offering me the opportunity to kill some "unresponsive" JavaScript, though if I do that, the form malfunctions.

This is with firefox-3.0.1-1.fc9.i386.

Comment 1 Gilboa Davara 2008-08-12 12:25:07 UTC
Same here.

Watching a 2.6Ghz 8C Xeon workstation timeout on a single web-form after ~60 seconds at 100% is very amusing.
Far less amusing is the fact that firefox MT model is somewhat lacking - once a tab hangs @100%, the rest of the browser hangs with it...

- Gilboa

Comment 2 David Lawrence 2008-08-12 20:31:05 UTC
*** Bug 458850 has been marked as a duplicate of this bug. ***

Comment 3 Adam Pribyl 2008-08-14 09:35:39 UTC
This problem got somehow critical with new bugzilla.. the search is almost impossible. How about to split the search form to more page?

Just for the reference:
https://www.redhat.com/archives/fedora-test-list/2008-August/msg00163.html

Comment 4 David Lawrence 2008-08-14 19:43:54 UTC
The reason for this is that the new Bugzilla is now using classifications where we not before. The classifications drop down when selected will update the products in the product drop down depending on which ones are in the classification. Currently when the product list is updated due to a selected classification, it will try to update the components, version, and milestones as well which is why it will bog down the browser. I have made a modification in our code that will not automatically update the components, versions, and milestones list when selecting a classification. Only the products list will change. Then the user will need to select a product from the new list to have the others updated. I have added a mouseover for the word "Product" that will explain what will happen when a product is selected.

I feel this is a suitable fix for this until a better solution is found that handles large amounts of components in a more efficient way.

Dave

Comment 5 Adam Pribyl 2008-08-15 09:06:15 UTC
NEXTRELEASE means that this is not applied yet? I'm still experiencing timeouts with search page...

Comment 6 David Lawrence 2008-08-15 16:39:39 UTC
Sorry should have stated. You will need to shift-reload the query.cgi page to cause your browser to update javascript code in its cache. We have the expiration or css and js set at 1 week.

NEXTRELEASE in current Bugzilla context means next update which we try to roll out on Thursdays for non-critical fixes.

Dave

Comment 7 Christopher Beland 2008-08-15 17:02:55 UTC
I did a shift-reload, and I see the popup for "Product".  I'm no longer getting the timeout when I select a "Classification", but I am still getting it when I select a "Product".

Comment 8 Christopher Beland 2008-10-25 00:01:22 UTC
I am still experiencing this problem when I select a Product, badly enough that I have to click "Continue" twice in dialog boxes which complain that "https://bugzilla.redhat.com/js/productform.js:290" is being unresponsive.

Comment 9 David Lawrence 2008-11-25 22:22:42 UTC
*** Bug 424691 has been marked as a duplicate of this bug. ***

Comment 10 David Lawrence 2009-01-08 15:58:05 UTC
We are pushing out an update to query.cgi that takes a more cgi approach to this issue and no longer relies on ajax to update the components/versions/milestones fields. Please open a new report after the update if the issue has not been resolved for you.

Dave

Comment 11 Christopher Beland 2009-01-11 07:31:52 UTC
Well, I no longer get the popup messages and CPU hosage, so it looks like the burden has been shifted from the browser to the server.  The page is still taking an annoyingly long time to load, though.  Obviously I have no idea what the bottleneck is on the backend, but it would be more pleasant to file bugs if there could be caching or some other kind of workaround.  Thanks for your efforts thus far!

Comment 12 Christopher Beland 2009-01-11 08:03:36 UTC
Sorry, the slow loading is for filing new bugs, waiting for https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora

Here we're talking about query.cgi, where I'm actually seeing very quick performance, but I think the Component and Version lists are now malfunctioning.  For example, if I choose "Fedora" and "Fedora" as Classification and Product, I can't find "smolt" on the Component list, and the Version field has 5.1, 5.1z, 5.2, 5.2z, 5.3, and 5.4.  (It should have some integers running up through 10, plus "rawhide".)

Comment 13 David Lawrence 2009-01-11 21:50:24 UTC
(In reply to comment #12)
> Sorry, the slow loading is for filing new bugs, waiting for
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora
> 

Yes we are still working on a solution for enter_bug.cgi and is different than the query.cgi prodblem.

> Here we're talking about query.cgi, where I'm actually seeing very quick
> performance, but I think the Component and Version lists are now
> malfunctioning.  For example, if I choose "Fedora" and "Fedora" as
> Classification and Product, I can't find "smolt" on the Component list, and the
> Version field has 5.1, 5.1z, 5.2, 5.2z, 5.3, and 5.4.  (It should have some
> integers running up through 10, plus "rawhide".)

Did you click the "Refresh Components/Versions/Milestones" button below the product multi select field? You need to click that each time you change your product selections (not classifications). Maybe it needs to be more descriptive on what needs to be done?

Let me know if that works better.
Dave

Comment 14 Christopher Beland 2009-01-12 03:12:49 UTC
Aha!  I did not notice there was a new button.  That's what I get for testing while sleepy.  Thanks!

Comment 15 Adam Pribyl 2009-01-12 08:29:33 UTC
Oh yes, pressing this button is necessary, this should be more obvious. How about to move the Components, Version and Target below this button?

Comment 16 David Lawrence 2009-01-12 18:12:12 UTC
(In reply to comment #15)
> Oh yes, pressing this button is necessary, this should be more obvious. How
> about to move the Components, Version and Target below this button?

I will create a new bug for this and see if we can make this more intuitive. My first goal was to get the query.cgi to at least be usable to most people. The ajaxification of the products/components/versions/milestones made the page hang for long periods since the component lists for Fedora for example is over 7000 long now. The query.cgi page was never originally coded to handle that many components in a single product.

Dave

Comment 17 David Lawrence 2009-01-16 17:03:13 UTC
*** Bug 478313 has been marked as a duplicate of this bug. ***

Comment 18 Mamoru TASAKA 2009-03-08 04:19:42 UTC
*** Bug 489132 has been marked as a duplicate of this bug. ***