Performance, Scalability and Tuning
Performance, Scalability and Tuning
This domain tests whether you can find the bottleneck with evidence and fix it at the right layer - model, query or infrastructure.
Core rules
- The database is usually the bottleneck. Mendix creates indexes for system attributes, associations and attributes used in entity access constraints; arbitrary filters on other attributes cause table scans.
- Retrieve once, work in memory. Retrieve-in-loop, per-row counts and per-row commits all multiply round-trips by list size.
- Use ranges and
Countfor pagination; never retrieve a million rows to show twenty. - The runtime is stateless across instances: two instances share the database but not memory. Anything cached in a microflow variable is per-request; anything that must be shared needs a shared cache or the database.
- Cache expensive external calls with a TTL-backed cache rather than calling on every page load.
- Measure before tuning: APM/metrics in the cloud portal, log-level statistics, the debugger, and the performance tab on a microflow show where the time actually goes.
Worked example
A dashboard takes 40 seconds. It retrieves all 200,000 orders, then filters in a microflow and aggregates in a loop. Two fixes: push the filter into the XPath constraint with a range so the database does the work, and replace the loop with an aggregate list activity. Result: one query returning 50 rows. The remaining cost is a per-row call to a currency service - that moves behind a cache with a five-minute TTL.
Traps
- Tuning Java heap when the real problem is an unindexed XPath constraint.
- Caching in a non-persistable entity and expecting it to be shared across instances.
- Adding a second runtime instance to solve a query problem.
- Optimising before measuring, then being unable to prove the improvement.