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.
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.
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 CLEVR 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’.