Bug 1583579 - [downstream clone - 4.2.4] Very slow UI if Host has many (~64) elements (VFs or dummies or networks)
Summary: [downstream clone - 4.2.4] Very slow UI if Host has many (~64) elements (VFs ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.9
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ovirt-4.2.4
: ---
Assignee: Ales Musil
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1548205
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-29 09:46 UTC by RHV bug bot
Modified: 2019-05-16 13:08 UTC (History)
12 users (show)

Fixed In Version: ovirt-engine-4.2.4.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1548205
Environment:
Last Closed: 2018-06-27 10:02:26 UTC
oVirt Team: Network
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3362161 0 None None None 2018-05-29 09:47:08 UTC
Red Hat Product Errata RHSA-2018:2071 0 None None None 2018-06-27 10:03:53 UTC
oVirt gerrit 88527 0 master MERGED webadmin: Fix low perfomance in setup networks popup 2018-05-29 09:47:08 UTC
oVirt gerrit 91088 0 ovirt-engine-4.2 MERGED webadmin: Fix low perfomance in setup networks popup 2018-05-29 09:47:08 UTC

Description RHV bug bot 2018-05-29 09:46:16 UTC
+++ 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)

Comment 1 RHV bug bot 2018-05-29 09:46:23 UTC
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)

Comment 6 RHV bug bot 2018-05-29 09:46:44 UTC
We need to research into this, and backport to 4.2 if possible.

(Originally by danken)

Comment 8 RHV bug bot 2018-05-29 09:46:53 UTC
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)

Comment 9 RHV bug bot 2018-05-29 09:46:58 UTC
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@redhat.comINFO: 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@redhat.com

(Originally by rhv-bugzilla-bot)

Comment 11 Michael Burman 2018-06-04 12:00:21 UTC
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.

Comment 17 errata-xmlrpc 2018-06-27 10:02:26 UTC
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

Comment 18 Franta Kust 2019-05-16 13:08:04 UTC
BZ<2>Jira Resync


Note You need to log in before you can comment on or make changes to this bug.