Bug 1640908
Summary: | Javascript Error popup when Managing StorageDomain with LUNs and 400+ paths | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Steffen Froemer <sfroemer> |
Component: | ovirt-engine | Assignee: | rszwajko |
Status: | CLOSED ERRATA | QA Contact: | mlehrer |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.2.0 | CC: | dagur, gshereme, guchen, gveitmic, lleistne, michal.skrivanek, rdlugyhe, rszwajko, sgratch, sraje, tashkena, tnisan |
Target Milestone: | ovirt-4.4.1 | Keywords: | Performance, Rebase |
Target Release: | --- | Flags: | lsvaty:
testing_plan_complete-
|
Hardware: | x86_64 | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | rhv-4.4.1-3 | Doc Type: | Enhancement |
Doc Text: |
Previously, if there were hundreds of Fiber Channel LUNs, the Administration Portal dialog box for adding or managing storage domains took too long to render and might become unresponsive. This enhancement improves performance: It displays a portion of the LUNs in a table and provides right and left arrows that users can click to see the next or previous set of LUNs. As a result, the window renders normally and remains responsive regardless of how many LUNs are present.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2020-08-04 13:16:11 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | UX | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Steffen Froemer
2018-10-19 07:00:22 UTC
Greg, from the storage perspective the code works as it should and creates the dialog, I guess the massive amount of elements "chokes" the browser, what can we do to fix it? profile it. you can see if there's some method the app is spending a ton of time in. Or you can see if there's a memory leak in that component. I can assist if someone has an environment with FC luns (or if there's a way to stub them in via database edits) Guy, can you provide Greg with a host with 400+ paths connected? Shani got me what I needed -- thanks! OK, so moving to UX now to note that you are currently handling it No corrent need from QE (Guy) This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1. Greg, any updates? (In reply to Michal Skrivanek from comment #14) > Greg, any updates? No. sync2jira sync2jira This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly The problem can be reproduced by replacing the response with static data (SanStorageModelBase.updateInternal()): - model.applyData((ArrayList<LUNs>) response.getReturnValue(), false, prevSelected, + List<LUNs> stubs = stub(500); + model.applyData(stubs, false, prevSelected, Perfomance tests results (on my laptop): 1. Chromium ~50 sec (see attachment performance_500_mocked_LUNs_chromium.webm) 2. Firefox ~22sec (see performance_500_mocked_LUNs_firefox.webm) Created attachment 1675993 [details]
performance on Chromium with static data (500 LUNs)
Created attachment 1675994 [details]
performance on Firefox with static data (500 LUNs)
Created attachment 1677534 [details]
offline paging added above the table
Profiling shows that rendering stage is the most time consuming. The LUNs table at Domains -> New Domain -> Fiber Channel is technically speaking a tree in which each node (row) is a GWT table component. Scenario described in this issue does not require all of the functionality (i.e. capability of displaying another GWT table as child node). However since the component is quite complex it would be time consuming to build a special purpose component only for this scenario. Due to this fact paging approach has been chosen. Solution is based on the paging code that was used so far in all tables (bottom right corner above the table). It has been extracted to allow re-use in the described scenario - see comment #25 for screen shot with the new look&feel. Note that for Fiber Channel screen the total number of items is displayed - differently then on other screens. This is caused by the fact that the underlying API does not support server side paging so all items are loaded in one request. Since the data is stored in the browser we know the size of the result set and are able to show this to the user. It's a small step towards design recommended by PatternFly 3 & 4 (see below). https://www.patternfly.org/v3/pattern-library/navigation/pagination/index.html https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/pagination#main-content Created attachment 1677572 [details]
paging - perfomrance with 500 mocked LUNs on Chromium
Since it is MODIFIED already then re-targeting to 4.4.1 Verified on : rhv-release-4.4.1-3-001.noarch vdsm-common-4.40.19-1.el8ev.noarch created 300 luns with 4 paths total 1200 FC from the UI : Storage > Doamin > New > provide the current DC / Cluster / FC / Host all the Luns available on the UI 300 luns on 6 pages each page 50 luns 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 (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), 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-2020:3247 |