Performance and Troubleshooting
Performance and troubleshooting
Performance work in Mendix is mostly about what reaches the database and what reaches the browser. On the server: XPath constraints on unindexed attributes, retrieves without a range that load thousands of objects into memory, retrieve-in-a-loop patterns, and microflows that commit per object instead of once. On the client: grids and list views that render everything, large binary attributes (images, files) loaded in overview lists, and pages that retrieve far more data than they display.
Troubleshooting tools to know: the log with levels Trace, Debug, Info, Warning, Error and Critical, log nodes defined per module, the Log message activity and Set log level; the Studio Pro debugger with breakpoints, which works on an app running locally from Studio Pro, not on a deployed cloud node; MxAssist Performance Bot, which flags anti-patterns such as unindexed XPath attributes and retrieves inside loops; and in Mendix Cloud, logs, metrics (CPU, memory, requests) and alerting.
Traps
- Logging an error at Info level, or logging to a node whose level is not enabled, so nothing appears in the log.
- Raising memory limits when the real cause is one enormous retrieve that should have been paged.
- Assuming the debugger is available on a deployed environment.
- Forgetting that commit inside a loop issues one transaction per object.
Rule of thumb
When a page or flow is slow, ask three questions in order: how many objects are retrieved, how many round-trips to the database, and is the XPath indexed? Index the attributes used in constraints and sorting, add a range to large retrieves, and commit once outside the loop.