Description of problem: 4.0.7 not working while using FF 42.0 and lower. for chrome it works prefect. Version-Release number of selected component (if applicable): 4.0.7 How reproducible: 100% Steps to Reproduce: 1. open webadmin dashboard tab in FF 2. 3. Actual results: dashboard loading indicator running forever. Expected results: nice & fast dashboard. Additional info:
does it happen only on FF42? is it working with FF ESR (45.2 currently)?
Since it's 'just' slow, I've reduced severity to high. I'm also wondering what are the result on the latest FF ESR (as Moran asked), which hopefully improved some performance.
(In reply to Eldad Marciano from comment #0) > Actual results: > dashboard loading indicator running forever. This seems more related to fetching data from Engine, rather than rendering stuff in the browser, is that correct?
Moving back to the engine, as the query is the issue.
We can confirm it has nothing to do with the browser. It is slow with many other browsers when running at scale of: - 2 DCs - 3 Clusters - 39 Hosts - - 48 SDs - 3000 VMs Browser that were tested: Firefox 45.2.0-1.el6_8.x86_64 (ESR): 04m17s Firefox 46.0.1 x86_64 OpenBSD 6.0 Beta: 04m01s Firefox 47.0+build3-0ubuntu0.16.amd64: 04m00s Chromium 50.0.2661.102 Ubuntu 16.04 (64-bit): 00m24s (maybe cache, cannot verify again ATM because of 503 Service Unavailable)
(In reply to Gil Klein from comment #6) > [snip] > > Chromium 50.0.2661.102 Ubuntu 16.04 (64-bit): 00m24s (maybe cache, cannot > verify again ATM because of 503 Service Unavailable) After trying again with Chromium 50, the avg. time to load was 4.4 minutes, which is close to the Firefox times. So browser type really doesn't matter in this case.
there is some performance improvements but it still takes more than 30 sec to be fully loaded. seems like we have another query which takes some long duration which fixed in patch set 6 - https://gerrit.ovirt.org/#/c/59089/ https://bugzilla.redhat.com/show_bug.cgi?id=1365443 verified failed qa
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Are you running with the original number of objects?
I ran it with the same active vms number, we should double test it with the same existing vms number.
I used to refresh my FF cache and verified it on top of 4.0.3-1 and it works pretty nice. FF version: 47.01
The caching will fix it.
Periodically updating query caching has been added. Under normal circumstances each dashboard data fetch will be served from cached data. The cache is initially populated when the engine starts so the first user to request dashboard data shouldn't incur the full cache warm-up penalty. Dashboard data is queried in 2 parts: - utilization trends from data warehouse (DWH) tables, and - inventory data from standard engine tables. By default, the utilization cache is updated once every 5 minutes and the inventory cache is updated once every 15 seconds. Both of these values are configurable with the ovirt-engine.conf mechanism.
*** Bug 1376428 has been marked as a duplicate of this bug. ***
The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.
To QE: when verifying the bug, please notice the following and test: Configuration options have been added to ovirt-engine.conf to: - enable/disable the background cache update - control the interval between updates for the inventory cache - control the interval between updates for the utilization cache
(In reply to Yaniv Kaul from comment #21) > To QE: when verifying the bug, please notice the following and test: > Configuration options have been added to ovirt-engine.conf to: > - enable/disable the background cache update > - control the interval between updates for the inventory cache > - control the interval between updates for the utilization cache Ok, is that ok to verify with defaults? currently the weak point was with lots of assets a specially vms and disks. we plan to verify that bug single SD (NFS) with as much as possible 3K vms.
didn't reproduced for firefox 45 and chrome 55.0 seems like we can shift this bug to other team, to investigate with lower firefox version.
Moving to verify, currently this bug not reproduced on firefox 45 or chrome 55.0 engine scale out profile: - 250 hosts - 3.7K vms - 1 SD - 1 DC