What are the first critical steps to reduce memory consumption in a Mendix application

0
Hi everyone,I'm currently working on optimizing memory usage in a Mendix application and would like to know from the community: What are the first and most impactful steps you recommend to reduce memory consumption? Are there specific areas (e.g., microflows, object handling, XPath queries) that typically cause memory bloat? Any real-world tips or tools (e.g., MxAssist Performance Bot, APM integrations) that helped you identify and fix memory issues? I've already reviewed the Mendix documentation and best practices, but I'm looking for practical advice based on your experience—especially things to prioritize early in the optimization process. Thanks in advance for your insights!
asked
2 answers
1

I would not worry much over this graph. IMHO this one will always max out because as long as there is memory much used pages and flows will be kept in memory and will only be freed if more memory is needed. You will see a drop if you reset your environment because then all cache is emptied. You will see the green line go up again untill a certain maximum.

Only when the lines meet you need to take action. But then the sollution will probably use a larger cloud node. The only thing you can do in your model for memory consumption is always clear lists when no longer needed, because that will instruct the app to no longer keep that list in memory. Then you control it instead of waiting on the model to decide when to release it.

Regards,

Ronald

 

answered
1

Server memory usage in itself isn't bad. You're screenshot doesn't necessarily indicate that there's a problem. It becomes a problem when your application slows down or when memory usage spikes so hard in a process that it doesn't finish or even restarts your application because of exhausted resources.

That being said, you could look at documentation like this and also this forum contains similar questions already answered.

First things that come to mind: if you have processes that (potentially) retrieve a lot of objects, use batches and taskqueues or java actions to end/start transactions. If you retrieve a lot of objects via integrations, (temporarily) store the results persistently instead of in non-persistent tables, especially if you're showing the results to the end user on screen. 

There is memory on the server and memory in the browser of the end user. Don't show too many objects at once. E.g. if you have a microflow source for a grid, be aware that browser memory will contain all the returned objects, even if the grid only shows 20 at a time. And use laze loading if you retrieve a lot of stuff in a lot of different tabs. Use a widget like the In View Content Renderer if a tab doesn't load lazily.

answered