Description of problem: When click the button "add to project", the next page is loaded very slowly. Pages except "add to project" page can be loaded quickly, such overview page. Version-Release number of selected component (if applicable): openshift v3.5.2 kubernetes v1.5.2+43a9be4 How reproducible: always Steps to Reproduce: 1. Get a project and click to overview page 2. Click to "add to project" button, and check the next page 3. Click "Ruby" Actual results: 2. The next page is loaded very slowly, about 10s 3. The next page is loaded very slowly, about 10s Expected results: 3 and 4: The next page is loaded quickly, like overview page which is about 2 s Additional info:
In 3.6 service catalog testing, always found it is same slow and an circle is spinning about same seconds when loading the items under "Browse Catalog" (As comparison, SaaS offerings section can be loaded immediately). Seems the root cause is as same as comment 0?
The SaaS offerings aren't requesting anything from the server, that information is directly in JS config, so I'd expect that to load instantly like it is. I recommend checking the network tab of the browser and seeing if any of the network requests on the catalog pages are taking a long time. Check for imagestreams and templates. This isn't something we see in our dev environments.
Sorry for late. Attached record of the browse catalog part spinning about 10s after login (or refresh), with network requests in screenshot.
Now the "Add to project" was load very slowly, sometimes even exceed 1 min, please have a look. Thanks! Test version: OpenShift Master:v3.6.153
Under the "Add to project", especially the 'Browse Catalog' tab is vvvery slowly, other two tabs are acceptable.
There is nothing we can do about this in 3.6, there are just that many templates OOTB and templates are huge because of all the objects they contain.
https://github.com/openshift/origin-web-common/pull/145 https://github.com/openshift/origin-web-console/pull/1919
Marking this as a duplicate of 1471033 since it has the same underlying cause. *** This bug has been marked as a duplicate of bug 1471033 ***