Bug 457843 - Very slow JavaScript while using query form
Very slow JavaScript while using query form
Status: CLOSED NEXTRELEASE
Product: Bugzilla
Classification: Community
Component: Query/Bug List (Show other bugs)
3.2
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
: Reopened
: 424691 458850 478313 489132 (view as bug list)
Depends On:
Blocks: 474289
  Show dependency treegraph
 
Reported: 2008-08-04 18:22 EDT by Christopher Beland
Modified: 2013-06-23 22:17 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 479725 (view as bug list)
Environment:
Last Closed: 2009-01-11 22:12:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher Beland 2008-08-04 18:22:32 EDT
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 08:25:07 EDT
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 16:31:05 EDT
*** Bug 458850 has been marked as a duplicate of this bug. ***
Comment 3 Adam Pribyl 2008-08-14 05:35:39 EDT
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 15:43:54 EDT
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 05:06:15 EDT
NEXTRELEASE means that this is not applied yet? I'm still experiencing timeouts with search page...
Comment 6 David Lawrence 2008-08-15 12:39:39 EDT
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 13:02:55 EDT
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-24 20:01:22 EDT
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 17:22:42 EST
*** Bug 424691 has been marked as a duplicate of this bug. ***
Comment 10 David Lawrence 2009-01-08 10:58:05 EST
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 02:31:52 EST
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 03:03:36 EST
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 16:50:24 EST
(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-11 22:12:49 EST
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 03:29:33 EST
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 13:12:12 EST
(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 12:03:13 EST
*** Bug 478313 has been marked as a duplicate of this bug. ***
Comment 18 Mamoru TASAKA 2009-03-07 23:19:42 EST
*** Bug 489132 has been marked as a duplicate of this bug. ***

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