[STCON-85] Inventory, Users etc Slow and Glitchy on View and Edit Created: 09/Jul/19  Updated: 19/Jul/19  Resolved: 19/Jul/19

Status: Closed
Project: stripes-connect
Components: None
Affects versions: None
Fix versions: 5.3.0

Type: Bug Priority: P1
Reporter: Cate Boerema (Inactive) Assignee: Michal Kuklis
Resolution: Done Votes: 0
Labels: performance, q3.1-2019
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: File focus-rerender.mov    
Issue links:
Relates
relates to STCON-81 Issue with props interpolation Closed
relates to FOLIO-2157 User Record Slow and Glitchy on Creat... Closed
relates to FOLIO-2165 Create correct builds for both snapsh... Closed
Sprint: Core: F - Sprint 68, Core: F - Sprint 67
Story Points: 13
Development Team: Prokopovych
Tester Assignee: Magda Zacharska

 Description   

Steps to repro:

  1. Log into folio-testing
  2. Go to Inventory
  3. Edit an Instance record
  4. Add a repeatable element such as an identifier
  5. Type into the identifier field - it takes a long time for the test you entered to display
  6. Please watch screencast - there are tons of issues here - too many to write up
  7. Another issue: go to Inventory, find an item record and view it, search for another instance and then open an item within that instance. It takes several seconds for the item data to refresh and show the relevant data for the selected item (it is showing the data from the previously viewed item for several seconds)

Expected: Entered text displays right away

Actual: Field is empty for 10+ seconds before the entered text displays

Additional info: the above is just one example of generaly slowness and glitchyness in Inventory lately. Ann-Marie passed on this feedback:
"When I type things into search boxes, it takes a few seconds for the typing to catch up - in users, checkin/checkout, inventory, etc.... Also, I kept pasting the search twice, and then having to back it out, and having to wait for the backspace to kick in. Ugh"

Screencast: https://www.screencast.com/t/if7u3iEgSj

Other performance issues seen recently:

  • Users app: FOLIO-2157 Closed
  • Settings > Circulation > Circ rules: Deleting patron notice policy takes too long https://www.screencast.com/t/5dsZUteT
  • Requests: Sometimes clicking the request queue number withing the request takes too long to show you the request queue list in the search results


 Comments   
Comment by Zak Burke [ 10/Jul/19 ]

In this screenie, all that happens is a little bit of keyboard interaction in a form field: typing new characters and then tabbing among fields. The borders that show up indicate which components are being re-rendered. You can see it's basically the entire form every time.

I don't know if this is an issue with redux-form itself or merely the way we are using redux-form, but it's clearly not helping us any.
focus-rerender.mov

Comment by Zak Burke [ 11/Jul/19 ]

The are many differences between the yarn.lock files on folio-release-core (where performance is OK) and folio-snapshot-core (where things are glitchy). That's gives us a lot of potential options to investigate, but it ... gives us a lot of potential options to investigate.

I'm working backwards with the snapshot branch's yarn.lock file (it's updated automatically every hour) to see if I can find a performance tipping point, (think git bisect) but it's a slow process.

Comment by Zak Burke [ 11/Jul/19 ]

Michal Kuklis narrowed this down to a bug fix we recently implemented. Essentially we were not correctly filtering a stream of events for changes and therefore our components did not always update as expected. Unfortunately, correctly filtering that stream is costly in terms of performance.

We are trying to figure out if we can have our cake and eat it too.

Comment by Cate Boerema (Inactive) [ 11/Jul/19 ]

Yay Michal Kuklis! What a relief to at least have a diagnosis. Which bug fix was it? Is this the same root cause as for FOLIO-2157 Closed ?

Comment by Zak Burke [ 11/Jul/19 ]

Yes, closed FOLIO-2157 Closed as a dupe. The original PR is stripes-connect #93. We should probably move this ticket to that project so we can correctly set the Fix Version field when this is wrapped up.

Comment by Cate Boerema (Inactive) [ 11/Jul/19 ]

You have a PR in already for a fix for this? Amazing. Thank you so much. I have moved this to STCON

Comment by Zak Burke [ 11/Jul/19 ]

We have a patch but we are still testing. The last time we patched a bug in stripes-connect it didn't go so well

Comment by Viktor Soroka [ 12/Jul/19 ]

Hi guys, I found that after the merge the tests in ui-circulation started to fail. I reverted locally the change and they started to work.

As I found it happens because the arePropsEqual function may happen to deal with react elements which are pretty deep objects. As I tried locally omitting such may resolve the issue.

Please check PR.

Comment by Cate Boerema (Inactive) [ 18/Jul/19 ]

Hi Michal Kuklis I don't have a great environment to test this in since I've broken both testing and snapshot, but I tried anyway. Users feels like it is working much better but I am still seeing the issue in Inventory where you type in a field and the entered text takes a long time to display. Reopening.

https://www.screencast.com/t/ZiLXB1CTe

Comment by Michal Kuklis [ 18/Jul/19 ]

Cate Boerema unfortunately there is nothing else we can do about this. I feel like we did everything possible given our current architecture (stripes-connect, redux-form). In order to improve it we would have to restructure things significantly (replace redux-form and switch to GraphQL).

But I would suggest reviewing this in folio-snapshot. The fix is already there and it should perform a bit better. The reason for it is that the snapshot env is built in production mode which improves the react performance. I'm hoping it will be good enough for the time being.

Comment by Michal Kuklis [ 18/Jul/19 ]

It also looks like folio-testing is misconfigured again which probably affects the performance too. I see these errors in folio-testing:

You are currently using minified code outside of NODE_ENV === 'production'. This means that you are running a slower development build of Redux. You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify or DefinePlugin for webpack (http://stackoverflow.com/questions/30030031) to ensure you have the correct code for your production build.

This was already fixed so I'm not sure why we see it again. I think after this is fixed again folio-testing should also perform a bit better too.

Comment by Cate Boerema (Inactive) [ 19/Jul/19 ]

Thanks for the context Michal Kuklis. I do think we will need to restructure things, as the performance is still too slow. But I understand that that's a bigger issue and out of scope for this release.

Things have improved significantly from when I first filed this ticket. I don't think the performance is a release blocker at this point so I will close this as done.

Thanks for all your help with this. We'll come back to the architecture restructure question later.

Comment by Michal Kuklis [ 19/Jul/19 ]

Perfect. Thank you Cate Boerema! Yes there are couple steps we can take to improve the overall performance. The big one will be to move away from redux-form.

Generated at Thu Feb 08 23:18:38 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.