Mendix

20 Performance tips for Mendix apps

Published 18-11-2020, last updated 01-02-2024 3 min read

A few years ago in 2016, I wrote a top 10 performance tips for Mendix. That list contains tips for Mendix developers to build good performing apps is still valid today! In this blog more tips are given in addition to the original tips.

#11. ANALYSE THE ISSUE USING TOOLING

This so you can find the spot to fix and not work in the dark. Also try not to optimize premature.

Google Chrome developer tools can measure loading of pages and indicate whether the time is spent in many small queries or just lots of data.

When you have it available, CLEVR application performance diagnostics (APD) for measuring and CLEVR code reviewer (ACR) for advice on common performance anti-patterns.

#12. KNOW THE PLATFORM SPECIFICS

Know the runtime settings. Through Mendix support I learned that Mendix 8 has a runtime option (DataStorage.UseNewQueryHandler) to generate Mendix 7 style queries and that those are a lot faster. This has become the default in Mendix 8.15.

Also understand XPath, how entity access xpath is applied, how inheritance is applied and thus the consequences of modeling for performance.

Understand page loading and usage of dataviews inside listviews for example. Sometimes they generate a lot of individual requests towards the server. This makes the wire protocol between browser and Mendix runtime very chatty and especially in low(er) latency situations this seriously reduces performance.

#13. MINIMIZE ROUND TRIPS

To minimize database roundtrip for example commit outside of a loop, query a lookup list before a loop and use find inside the loop.

To minimize client server roundtrips on native mobile use offline data with proper synchronization.

Use nanoflows in client side logic, of course with actions not doing server calls.

#14. PREVENT LONG DURING AND/OR LARGE TRANSACTIONS

Experience learns that Mendix slows down on large long running transactions. So commit transactions in batches using special java actions as available in the community commons module.

Another reason to prevent long during transactions is that modified data in the transaction is locked for further modifications in the database, so you run the risk of timeouts due to locking.

Also good advice is to commit at the end of a microflow, to make the lock duration as short as possible.

And always commit different entities in the same order, so deadlock cannot occur.

#15. APPLY MODEL-VIEW-CONTROLLER PATTERN

Create a non-persistent entity for a page, collect only presented data there and minimize data sent to client. Of course you now need to manage the data including security to match the underlying data model.

Of course this tip make the model more complex, but as always architecture choices need optimization and sometimes performance goes over maintainability.

#16. USE ASYNCHRONOUS PATTERN

If a user does not have to wait for the result, perform the action in the background asynchronously. If the user does want the result, but it still takes a long time to get, use a pattern where the user can see progress and navigate away and return to see progress again.

#17. DECOUPLE DATA

Mendix loads the references and reference set ID’s when using an entity. So create a soft link using your own keys or a middle entity instead of a reference set so the reference is on the other side and only loaded when you need it.

#18. PRE-CALCULATE DATA

If possible you can pre-calculate data when the number of mutations is low (enough).

This sometimes can be applied to replace calculated attributes.

Also smart data models can be setup to calculate a runtime model out of a configuration model with the goal to optimize and simplify queries.

#19. USE PARALLELISM

If you need to process a lot of data without a dependency between records you can consider processing the data in parallel. There are some App store modules that can help here. The essence is to create workers that process a record and a pool to manage workers, since you don’t want all records to be worked at simultaneously.

#20. USE HIGH CODE POSSIBILITIES

Even in a low code tool you sometimes need high code extensions, for example java code with better control over logic and faster loops. Also using OQL to do complex queries and even using SQL to use database specifics or even more complex queries can help in certain cases.

This is seen as a last resort and hence the last tip in this additional list.

CONCLUSION

I hope this list helps you create even faster applications. Additional sources to learn how to solve performance issues and stand on the shoulders of other developers can be found on the internet.

Search for ‘Mendix performance’ and you can find for example: