Clicking 'edit' to change component on a Fedora bug produces a spinner, and then finally loads about 30 seconds later. Firebug says what's happening is we're doing POST jsonrpc.cgi of: {"method":"Product.get","params":{"names":["Fedora"],"include_fields":["components.name","components.is_active"]},"id":1,"version":"1.1"} Which then returns about 100k of json listing all the components. Some observations: - The wait time for the response is 28s, the actual transfer is only 860ms. So clearly this list is being generated fresh every time. That seems unfortunate, it's not like component lists change that often. One would think the server could keep a cache for that. - Better yet, the component lists could be kept in static URLs containing a sequence number (for when the lists change) and a reasonably long cache expiry, which would let the _client_ keep copies of the lists instead of having the server regenerate them all the time. - The actual json returned includes an is_active value for every component, despite that (in this example) only two of them have a value other than true. Seems like you'd do better to return only active components (assuming the rest of the js on the page doesn't do anything special with inactive ones, which I've not checked), which would probaly cut about 50% off the file size of the component list itself. This request overlaps with bug #1157849 a bit I guess, since that would turn the component list into an ajaxy typeahead thing instead of a dropdown. I don't really care what form the solution takes as long as I'm not waiting half a minute every time I want to fix a bug's component.
(In reply to Adam Jackson from comment #0) > Clicking 'edit' to change component on a Fedora bug produces a spinner, and > then finally loads about 30 seconds later. Firebug says what's happening is > we're doing POST jsonrpc.cgi of: > > {"method":"Product.get","params":{"names":["Fedora"],"include_fields": > ["components.name","components.is_active"]},"id":1,"version":"1.1"} This is a known problem. Fedora has an insanely large component list that is much larger than any other product in any known Bugzilla installation. The list is currently >17,000 components and still growing. Bugzilla's UI was not really designed to handle lists of that size, and neither were some browsers -- Chrome limits list boxes to 10,000 items. > - The wait time for the response is 28s, the actual transfer is only 860ms. That's similar to statistics that I have collceted in the past. > So clearly this list is being generated fresh every time. Bugzilla currently relies on the underlying database to cache the list in it's query cache. That's fine for most Bugzilla installations where the component lists for single products are typically less than 100 items, but doesn't work so well in our case. > That seems unfortunate, it's not like component lists change that often. The last time I looked into the rate of change (mid 2013), it was 300-400 times a month - basically every time a Fedora RPM is added, renamed, or retired. > One would think the server could keep a cache for that. Bugzilla 5.0 will introduce memcached support, which we expect will help to improve the database-related portion of the total time. The upstream Bugzilla project haven't set a timeline for 5.0 yet, however, so right now I can't give a reliable date for Red Hat Bugzilla moving to 5.0. > - Better yet, the component lists could be kept in static URLs containing a > sequence number (for when the lists change) and a reasonably long cache > expiry, which would let the _client_ keep copies of the lists instead of > having the server regenerate them all the time. We have considered something like this in the past. The conclusion was that it would be fragile, and that the upstream Bugzilla project would be unlikely to accept the patch (as the problem is unique to Fedora and the patch would be unlikely to benefit anyone else enough to justify the increase in complexity). > - The actual json returned includes an is_active value for every component, > despite that (in this example) only two of them have a value other than > true. Seems like you'd do better to return only active components (assuming > the rest of the js on the page doesn't do anything special with inactive > ones, which I've not checked), which would probaly cut about 50% off the > file size of the component list itself. The is_active value is used in some places in Bugzilla. For example, a bug that has an inactive component is fine to keep it, but a new bug cannot be filed against an inactive component and an exicting bug canot be moved to an inactive component from another component. As you correctly noted above, the total time is currently dominated by the time to extract the component list from the database. Improving that will have a much greater impact than dropping the is_active field from the results. > This request overlaps with bug #1157849 a bit I guess, since that would turn > the component list into an ajaxy typeahead thing instead of a dropdown. I > don't really care what form the solution takes as long as I'm not waiting > half a minute every time I want to fix a bug's component. Yes, Bug 1157849 is our preferred way to tackle this problem in the near term -- reduce the database query time by making a more specific query that will execute faster and return a much smaller result set (and provide a more usable UI, as trying to pick an item from a 17,000 element list is painful). In the longer term, we also have plans to improve the server-side performance of Bugzilla by moving to Bugzilla 5.x, upgrading system hardware and improving the architecture of the database cluster. We are making progress in these areas, but unfortunately that work is currently constrained by available resources and funding, so progress isn't as rapid as we would like. *** This bug has been marked as a duplicate of bug 1157849 ***