detect-and-resolve-performance-issues

[Michiel-Bijlsma]

Please use the form below, leaving the prefilled data to help us. Thank you.

Page link: detect-and-resolve-performance-issues

Document link: detect-and-resolve-performance-issues.md

My Issue/Suggestion

Hey team, I've written down some idea's/feedback/suggestions. Hopefully these are helpfull next time when editing this page.

Intro

In the picture of the microflow, when going to the UI part (second decision split on the left side) there is a mention of "Firebug result", but the document fails to explain this tool and how to use it and analyze the results.

3.2 Slow loads

Could be interesting to add a bit more information about the developer tools and how to analyze the requests.

4.3 Microflow time stamps

Alternativley, it is possible to use the TimeMeasureStart and TimeMeasureEnd java actions in the community commons module, they do pretty much the same as described in the current explaination but as added benefit that it can be placed in different microflows without the need of passing the start time from one to another microflow.

5.1 Slow database retrieves (or commits)

You can setup the https://docs.mendix.com/refguide/custom-settings/#LogMinDurationQuery for debugging slow database connections/xpaths. For debugging purposes you can set the value to 500 ms to see all the retrieves/commits that take longer than 500 ms.

5.2 Refresh in Client

Also, be carefull, since a refresh on one object might result in mutiple refreshes down the line (for instance with nested dataviews)

5.4 (new subject)

If you notice that with bigger operations a microflow becomes slower, it might be that there is something kept in memory. For instance a commit list that grows over 10k objects might impact the application (memory) performance.