+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1548205 +++ ====================================================================== Description of problem: Not sure if isolated to VFs, but once the number of VFs approaches 64 the UI slows to a crawl. This one seems quite slow: Host -> Network Interfaces And this is unusable: Host -> Network Interfaces -> Setup Networks. Interestingly, with 32 VFs I don't see any degradation (neither does the customer). But as we approach 64 it gets very slow. There must be something with far from non-linear complexity causing this. Version-Release number of selected component (if applicable): rhevm-4.1.9.2-0.1.el7.noarch Chrome (customer, version pending) Firefox 58.0.2 Quantum (mine) How reproducible: 100% Steps to Reproduce: 1. Deploy attached hooks to a host. 2. Right click -> Management -> Refresh Capabilities 3. Navigate to Network Interfaces, start clicking around. Exit, enter again... Actual results: Slowness Expected results: More responsive UI. Additional Information: In FF58, "Web Process" goes to 100% CPU and high memory usage. (Originally by Germano Veit Michel)
Created attachment 1399660 [details] vdsm hook to simulate 64 VFs VDSM hooks to reproduce the problem after_get_caps: 10_fakesriov # place this hook to reproduce the problem after_hostdev_list_by_caps: 10_fakesriov # place this hook to reproduce the problem (Originally by Germano Veit Michel)
We need to research into this, and backport to 4.2 if possible. (Originally by danken)
So to sum up what I have discovered: 1) Host -> Network Interfaces This panel is slow because PatternflyListView is doing too much expensive updates too quickly. And after certain number of interfaces this updates are produced quicker than their computation is done. This leads to very rapid slow down after some point. E.g. For me it was ~128 interfaces. To prevent those issues we should disable updating every element on selection change. We could also set lower refresh rate (currently 5s) but this wouldn't help that much. IMO the best thing we could possibly do is implement differential update. Because I think that not every interface is updated in the 5 sec interval. This might be tricky to implement but will save us a lot of time later. 2) Host -> Network Interfaces -> Setup Host Networks This is pretty straightforward. I have introduced redraw problem with my LLDP patch which can be observed only with a lot a interfaces. I am working on patch that should deal with this problem. Another thing that is taking a lot of time is ordering the interface commands by name (IMO this can be disabled). That's for the initial rendering part. Once this dialog is rendered there is no further update and the dialog should be smooth. It isn't because of the problems I have mentioned in 1). The network interfaces are always redrawn in the background behind the dialog. So to solve slowdown after render in the dialog we have to solve the issues in 1). (Originally by Ales Musil)
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.2.z': '?'}', ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.2.z': '?'}', ] For more info please contact: rhv-devops (Originally by rhv-bugzilla-bot)
Verified on - 4.2.4.1-0.1.el7 Few notes: - The performance now is much better and smoother. The setup networks dialogue pop up is now loading much faster and scrolling the multiple NICs in the pop up is smoother. - Ales's fix is handled the behaviour of the LLDP which now instead of rendering the dialogue again just updates the tooltips - Note that almost any other operation in this pop up triggers render, so operation like attach networks are still expected to have some delay. I will open a RFE to handle this.
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/RHSA-2018:2071
BZ<2>Jira Resync