Description of problem: To redirect Developer Catalog/ OperatorHub page take very long time to response user. From Performance tab of dev console, it shows the console was staying at idle status in most of loading time. The two pages take 30 seconds more to show contents usually. Version-Release number of selected component (if applicable): 4.2.0-0.nightly-2019-07-03-171807 a15ac81be7f7479b1d527a28c780fd09ce123710 How reproducible: always Steps to Reproduce: 1.click Catalog->developer catalog page & Catalog->OperatorHub Page 2. 3. Actual results: The two pages take 40 seconds more even 60s to show contents usually. Expected results: Should show page in an acceptable time. Additional info: more info refer to attachments
Created attachment 1588289 [details] idle
Created attachment 1588292 [details] it cost much time to load templates
Can you open separate bugs for each page? The underlying requests are very different. For each page, can you collect a HAR file? 1. Open Google Chrome 2. Open Developer Tools (Ctrl-Shift-I) 3. Switch to the Network tab 4. Reproduce the problem 5. Right click a row in the network tab and select "Save all as HAR with content" I can't seem to open perf2.png for some reason. The file might be corrupted.
Created attachment 1588610 [details] OperatorHub_HAR.open
Created attachment 1588611 [details] OperatorHub_HAR_preview
I upload the original HAR file and HAR statistics preview about OperatorHub page to analyze this issue in this bug.
*** Bug 1736817 has been marked as a duplicate of this bug. ***
https://github.com/operator-framework/operator-lifecycle-manager/pull/1002
The operatorHub page will take around 7-8s to response users. It should be in acceptable range. Verified this bug. quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:eb70f4a6151b3edb669db9a4928cd2b81e1ed31d7d35f937ade1183be8f4d3d9 io.openshift.build.commit.id=ac956c76e1be5fb7f48ae554d6b95e7716e6a34b
Hi, Han I think there is the same issue in 4.1, do we have a bug to trace it for 4.1?
Normally, the page on 4.1 cluster takes 10s to response users, I think it is little bit slow but should be acceptable range. cc Sam, how do you think about it?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2922