Skip to content
This repository has been archived by the owner on Dec 13, 2020. It is now read-only.

Fix frontend memory leaks #1071

Closed
teosarca opened this issue Jul 24, 2017 · 7 comments
Closed

Fix frontend memory leaks #1071

teosarca opened this issue Jul 24, 2017 · 7 comments

Comments

@teosarca
Copy link
Member

Steps to reproduce

It seems the frontend consumes quite a lot of memory (might be some memory leaks?).
My test case was:

  • open a window, e.g. receipt schedules https://w101.metasfresh.com:8443/window/540196
  • open chrome task manager (in windows that's shift-ESC)
  • refresh the frontend page couple of times (e.g. 10 times)
  • observe how the memory consumption is rising

Expected behavior

Identify the fix the memory leaks.

Thanks @wiadev for bringing this up.

@teosarca teosarca added this to the Backlog milestone Jul 24, 2017
@cadavre cadavre modified the milestones: Backlog, 2017-31 Jul 25, 2017
@cadavre cadavre self-assigned this Jul 25, 2017
@wiadev
Copy link
Contributor

wiadev commented Jul 28, 2017

Yes, memory does leaking in application.

Possible places (not limited to):

  1. Trace Redux reducers for optimal state updates
  2. Check for components referring when not needed to large objects (and arrays) don't allowing to be freed by garbage collector
  3. Make sure to optimize re-creating of components when not needed

Major memory wasters:

  1. DocumentList
  2. Forms

Other resource-consuming sources might include Websockets, need to carefully verify what they're referring and ensure data gets freed when not needed.

@wiadev
Copy link
Contributor

wiadev commented Jul 28, 2017

please keep in mind that this is needed, but risky change

@wiadev
Copy link
Contributor

wiadev commented Jul 28, 2017

this story will result large impact on many areas on site. So needs to be carefully checked both on dev and QA ends. QA phase might take significant time.

@cadavre
Copy link
Contributor

cadavre commented Jul 28, 2017

Tested on Chrome, macOS.

Page with /window/540196 takes regularly ~270MB.
This page (GH issue) takes ~210MB in comparison.

After refreshing page once or 20x it grows to ~310MB but never more.

Might be OS GC issue? Because it isn't one for me and if it is "risky change" and "will result large impact on many areas on site" maybe it's worth making some more research on different test envs?

Attaching detailed performance scan for 10x refresh:
zrzut ekranu 2017-07-28 o 12 27 46

(Chrome 59.0.3071.115, macOS Sierra 10.12.6)

Chart on the bottom is memory. GC works quite well and instant, also after all refreshes gets to initial value.

Please provide your env and performance dumps.

@wiadev
Copy link
Contributor

wiadev commented Jul 28, 2017

Try to switch between forms and document lists for example.
Not refreshing single page.
Otherwise figures aren't quite correct

@cadavre
Copy link
Contributor

cadavre commented Jul 28, 2017

Made around 15 switches between one list and different document:
zrzut ekranu 2017-07-28 o 12 35 12

In task manager never more than 360MB. On chart you can see that memory levels are on almost-initial level at the end.

Could you provide yours chart for comparison?

@wiadev wiadev self-assigned this Aug 3, 2017
teosarca added a commit that referenced this issue Aug 16, 2017
Checked for memory leaks, event handlers cleanup #1071
@wiadev wiadev removed their assignment Aug 16, 2017
metas-mk added a commit to metasfresh/metasfresh that referenced this issue Aug 16, 2017
Adding new issue to release 5.23
metasfresh/metasfresh-webui-frontend-legacy#1071 Fix
frontend memory leaks
@metas-mk metas-mk modified the milestones: 2017-31, 2017-40 Oct 4, 2017
@metas-lc
Copy link

IT
tested the case above -> works fine

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants