Top 10 performance improvement tips for Mendix

As promised a few blogs ago, I have written this blog with my top 10 performance improvement tips for Mendix. This blog is technical in nature and assumes knowledge of the Mendix modeler and some infrastructure knowledge, like what a database index does or how web server compression would help.

This top 10 is of the top of my head and based on experience. Without further introduction I present to you my list:

#1. CREATE INDEXES

Yes, really create indexes. As soon as an entity (a table or more tables in the case of inheritance) contains a substantial amount of data you will notice a performance degradation. Find out what searches are done. Check the model for xpaths that use attributes. Also check your search forms with grids.

#2. MINIMIZE USE OF CALCULATED ATTRIBUTES

They execute every time a record is loaded. And many times if the calculated attribute is used in a grid.

If you do use them, make them read-only aka without side-effects and make them fast!

#3. LIMIT DATA VOLUMES

A grid loads chunks, so a smaller chuck size can improve performance.

Think about what data the client needs. With permissions or model design you can make sure a minimal set of attributes is sent to the client. This also applies to the complexity of the form in the modeler.

Drop-down references can take a really long time to load. Both because of the data volume and also the client-side JavaScript engine time building up the menu.

Archive data if you can.

#4. AVOID LOOPS IN LOOPS

The iterations of loops in loops are executed many times and a lot of small pieces make a slow puzzle.

If you cannot avoid loops in loops, try to minimize the amount if iterations, try to do work outside the loops where possible, try using in memory lists instead of retrieves.

#5. COMMIT AS LATE AS POSSIBLE

This prevents locking a record and having other concurrent users wait.

Scheduled events or batch jobs should work in small batches/chunks. Otherwise they lock data for a long period of time.

#6. AVOID INHERITANCE

Mendix manages separate tables for each inherited entity. Mendix has separate security for inherited entities, so especially be cautious with xpath constraints on entities with inheritance and a lot of data. I’ve seen the generated SQL statements go from half a page to 30 pages (A4) and the corresponding response time from below 2 seconds to above 30 seconds.

#7. USE THE MENDIX OPTIMIZATION RETRIEVE+COUNT

Mendix optimizes a database retrieve followed by an aggregate (count) if the list resulting from the database retrieve is not used elsewhere. So sometimes it might help to retrieve twice, because the first retrieve is optimized and the second is only executed in certain business cases

#8. MINIMIZE THE USE OF REFERENCE SETS

Mendix preloads data of references sets even if the data is not needed. So a reference set with a lot of references in it gets loaded every time the entity is loaded in for example a microflow.

Also minimize the use of the both option on reference sets. This creates the problem on 2 sides and this option is hardly ever needed.

#9. INTRODUCE A PROXY WEB SERVER

For those on premise installations a web server that serves static content and compresses all communication really helps a lot.

For those in the Mendix cloud: you’re lucky. Mendix has already arranged this for you.

#10. USE FASTER HARDWARE

Trivial, but still often an option on the server side. Add ‘AppEngines’ in the Mendix cloud or extra virtual capacity in your data center.

Mendix is based on a JavaScript framework and an older browser can be really slow. So use the best browser you can. In the past we had Google frame under IE6 or IE7. Those days are gone I hope.

CONCLUSION

I hope my list helps you create faster applications. If you would like to debate about the contents or if you are in desperate need of assistance with your performance challenges, feel free to drop me an email.

The Mansystems Application Performance Management (APM) Suite of tools can greatly assist you in pinpointing performance issues, even before they arrive via complaints of end users. I have written more about the application of this suite of tools in blog ‘just-in-time performance management’. You can also read a one pager on our website.

Bart Tolen

Bart Tolen has a master of engineering in applied physics and has worked with Mendix since 2010. He is a Mendix MVP, Solution Architect, and specialized in performance. Bart is the thought leader and designer of Mendix APM.

OUR LATEST TWEETS