Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 214842 - RFE: Advanced Query page is uncacheable and big, thus slow
RFE: Advanced Query page is uncacheable and big, thus slow
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
All Linux
high Severity high (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
David Lawrence
: FutureFeature
: 199031 376091 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-11-09 13:09 EST by Jan Kratochvil
Modified: 2013-06-23 22:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-02 08:11:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
browser screenshot (124.68 KB, image/png)
2008-01-22 11:31 EST, Adam Pribyl
no flags Details

  None (edit)
Description Jan Kratochvil 2006-11-09 13:09:25 EST
Description of problem:
While on slow link (40kbit/s) working with RH Bugzilla is very slow (80 sec).
The Component list on each Bug page is also pretty long.

Steps to Reproduce:
1. https://bugzilla.redhat.com/bugzilla/query.cgi?format=advanced

Additional info:
Could you set the main query page as cacheable?
Could you use external cacheable Component list via JavaScript for each Bug?
Understood it is probably not a high priority, I should also get a better
connectivity back again later.
Comment 1 David Lawrence 2007-08-08 16:43:48 EDT
We are looking into a solution for this problem for our next release.
Comment 2 Adam Pribyl 2008-01-22 11:31:54 EST
Created attachment 292533 [details]
browser screenshot

I am not sure, if this is exactly the right bug, but complains about
bugzilla.redhat slowness seem to be pretty general. 
One example:

I also go often to bugzilla here and there and it's awfully slow. On query page
my browser always stops with complains about script executing too long
(attached). Is there really no better way to choose components etc. - e.g.
split the choice to more pages?
Comment 3 David Lawrence 2008-01-22 11:57:38 EST
*** Bug 199031 has been marked as a duplicate of this bug. ***
Comment 4 David Timms 2008-01-23 07:38:40 EST
There has been some improvements in bugzilla show bug response speed of page
completion, I think mainly to do with showing a single value in the drop down
lists, and providing the update field { Update Products etc } links. Although
that time saving only seems to happen after the first load.

You guys have probably thought of these possibilities already but here goes anyway:
- drop down just shows 0-9,a-z  {ignore case},
    then AJAX load the list of items starting with that letter in a drop down
next to it.
- have search for match text in a text field, as the default for any drop down     
    with > 20 items, returning results to a separate drop down list to select from.
- still provide a -show all- for those who have no idea and need the full list.
- delay load of component list until the product and version {or additional
selection any version} have been selected.
Comment 5 David Timms 2008-08-16 02:43:16 EDT
With upgraded bugzilla.redhat.com, a typical Fedora|Fedora selection takes over 30 seconds to complete the components {packages} list. After 20 seconds, firefox's unresponsive script dialog kicks in, and CPU use stops until continue is pressed, then another 10 seconds until it's ready. [AMD Athlon 2GHz, ADSL2+ network connection]. I don't remember if that is shorter or longer than before; the popularity of packaging for fedora means that it will take longer as more packages are added.

Perhaps until better code comes along, the initial load of the advanced query page could:
- just have a text entry box for component - no prefill
- add text to say opening component list in another tab
- as page finishes loading, trigger an open in tab of a text file containing the component list; make sure the page content is cached by the browser ;-)
- user copies and pastes appropriate item from list into advanced form.
- search ?

2. Selecting say documentation after the above test also takes about 30 seconds with CPU at 100%. The component list for doc'n is 34 items. Perhaps there is also a big hit to consider in the browser in terms of deleting item from the list - if they are in a delete loop, can the list be instantly cleared instead ?
Comment 6 David Lawrence 2008-11-30 18:29:10 EST
*** Bug 376091 has been marked as a duplicate of this bug. ***
Comment 7 Chris Ward 2009-04-02 02:51:46 EDT
I think this problem has been fixed. Loads for me now in about 5 seconds when i load any page, and for example, when i refresh with Fedora components/milestones/... selected. I vote - (CLOSE->CURRENTRELEASE)
Comment 8 Jan Kratochvil 2009-04-02 03:58:02 EDT
The performance I find acceptable now although it is still some pain when using it over GPRS.  The component list is still being loaded each time again with no caching of it.
Comment 9 Chris Ward 2009-04-02 07:53:44 EDT
Can we close this bug then, since the load performance is acceptable now? or are you still requesting the caching to be implemented?
Comment 10 Jan Kratochvil 2009-04-02 08:11:51 EDT
OK, closed, rather avoiding BZ when on GPRS.

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