Hide Forgot
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.
We are looking into a solution for this problem for our next release.
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: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01075.html 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?
*** Bug 199031 has been marked as a duplicate of this bug. ***
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.
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 ?
*** Bug 376091 has been marked as a duplicate of this bug. ***
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)
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.
Can we close this bug then, since the load performance is acceptable now? or are you still requesting the caching to be implemented?
OK, closed, rather avoiding BZ when on GPRS.