Bug 214842 - RFE: Advanced Query page is uncacheable and big, thus slow
Summary: RFE: Advanced Query page is uncacheable and big, thus slow
Alias: None
Product: Bugzilla
Classification: Community
Component: Bugzilla General
Version: 3.2
Hardware: All
OS: Linux
high vote
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact: David Lawrence
Keywords: FutureFeature
: 199031 376091 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-09 18:09 UTC by Jan Kratochvil
Modified: 2013-06-24 02:43 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2009-04-02 12:11:51 UTC

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

Description Jan Kratochvil 2006-11-09 18:09:25 UTC
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 20:43:48 UTC
We are looking into a solution for this problem for our next release.

Comment 2 Adam Pribyl 2008-01-22 16:31:54 UTC
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 16:57:38 UTC
*** Bug 199031 has been marked as a duplicate of this bug. ***

Comment 4 David Timms 2008-01-23 12:38:40 UTC
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 06:43:16 UTC
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 23:29:10 UTC
*** Bug 376091 has been marked as a duplicate of this bug. ***

Comment 7 Chris Ward 2009-04-02 06:51:46 UTC
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 07:58:02 UTC
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 11:53:44 UTC
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 12:11:51 UTC
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.