65052 - Improve loading times of query.cgi with large numbers of products/components

Status: NEW

(Bugzilla :: Query/Bug List, enhancement, P1)

Description

[Matthew Tuck [:CodeMachine]]

I was discussing bugzilla installation with some people and the question came up
as to what would happen with a very large number of components and/or products.

Apparently redhat have a large number in their hacked up bugzilla, and query.cgi
can be around 200K or so and take quite a while to load.

So this installation would possibly want to add a large number of products,
maybe in the hundreds, but assumedly wouldn't want this to occur.

Therefore I think it's desirable to have prefs in editparams.cgi that:

(a) all product listings are converted to text boxes, with links to a full
product list next door
(b) all component listings are converted to text boxes and a similar link

This way the load time should be reasonable for them.

Comment 1

[Sean Richardson]

A corrolary: the entered product and component values would have to be 
error-checked against the legal_product or legal_component lists, as
appropriate, and the user sent to an error page linking or incorporating
the relevant full list(s) (one error page for both potential errors, please!).

Also, if the official component name have initial caps (likely) and users
type in component names all-lower (also likely), bug 64192, "Altering 
Capitalisation of a Component Name causes SQL failure", may need to be 
fixed for maximum robustness, by making bugzilla internally case-insensitive 
for product and component names at all times.

Comment 2

[Matthew Tuck [:CodeMachine]]

Does that mean:

- We prevent case insensitive duplicate component names?  What do we do about
old installations?
- We allow duplicate names, but if two match, use the one with correct
capitalisation, or if neither has, allow the user to choose?

Bug #35924 is an alternative here.

Comment 3

[Matthew Tuck [:CodeMachine]]

We should be able to do this in BZ3, I doubt very much we'll see this earlier.

Comment 4

[Dave Miller [:justdave]]

The Bugzilla 3 component is going away.  We're going to depend on the Milestones 
for this.  At the time this component was created, we didn't have milestones for 
Bugzilla.

Comment 5

[Matthew Tuck [:CodeMachine]]

Actually it seems these lists might be small compared to the Javascript that
gets brought down.

Comment 6

[Hixie (not reading bugmail)]

Bailing on Bugzilla 3.0 due to too many other commitments.

Comment 7

[Max Kanat-Alexander]

I think this would be a nice thing to solve with AJAX--we could retreive the product and component lists with AJAX instead of putting them all right on the page's JavaScript.

Comment 8

[Max Kanat-Alexander]

Looks like Firefox did some strange selecting of the group radio boxes on the mass-change page when I clicked refresh in my browser before that last mass-change. This is not really a security bug. :-)

Comment 9

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 10

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

Comment 11

[Mikhail Gusarov]

I've got (hacky) implementation for AJAX-based selection for components on bugzilla.altlinux.org (we've got ~78000 components, which is way too many :). You can use test.bugzilla.altlinux.org to play freely with it. 

Will post the series of (polished) patches to implement it.

The general idea is as the following:

In AJAX-capable browsers:
* Small components lists (e.g. less than 100 (configurable)) show up as
  comboboxes, exactly as in current Bugzilla
* Large components lists show up as editboxes with completion

In AJAX-incapable browsers:
* Small components lists show up as comboboxes
* Large components lists show up as editboxes

For the pages where set of components depends on selected products, the widget is changed depending on the amount of components for the selected set of products.

Comment 13

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Moving open bugs with topperf keyword to triage queue so they can be reassessed for performance priority.