How to check slow performance of microflow

0
hello all,I need to identify which SQL query or database call is causing slowdowns in my complex microflow during page load. I'd like to explore using AI to help with this analysis, but I don't have direct database access on my deployed Mendix server. What options are available for this situation?Context: I'm working with a complex microflow that handles page loading. The page performance is slower than expected, and I need to pinpoint the bottleneck.Constraint: I cannot access the database directly on the deployed Mendix server.
asked
3 answers
2

If you have a slow and complex microflow, you could add timing information to the flow and log the results at various stages of its execution. This should give you a basic understanding of how long various parts of the microflow take to execute and help you narrow down the cause of the slowness. I wrote a blog post on timing microflows a few months ago that may be of help if you want to take this approach.

https://medium.com/mendix/timing-mendix-microflows-1f85df492729

Apart from this, Mendix publishes best practices in the documentation. Make sure your app is following this advice to ensure the best performance.

https://docs.mendix.com/refguide/community-best-practices-for-app-performance/

I hope this helps. Good luck!

answered
0

I 100& agree with timers and logs. You could do live conditional debugging in your app and take note of the slow points.


You could also try running it locally using the DB from your server as a local Postgres DB. Then use AI mcp + mxcli to help troubleshoot the bottlenecks. Additionally I normally run jconsole locally to see where the memory spikes are happening.


https://community.mendix.com/link/spaces/community/exchanges/740

https://docs.mendix.com/developerportal/deploy/monitoring-mendix-using-jmx/


If you are seeing page load issues, it might be possible it is a bloated client state and not the microflows.

answered
0

Hi Raghavendra,


You don't necessarily need direct database access to identify the slow query. I would first separate the problem into microflow activity time and database query time.


For a complex microflow that is triggered during page loading, I normally start by measuring the individual parts of the microflow rather than trying to inspect the database directly.

One simple approach is to add timestamps around the suspicious activities:

Start
  |
  |-- Retrieve A
  |-- Retrieve B
  |-- Call Sub-Microflow
  |-- Commit
  |
End

Log the elapsed time after each relevant section. This quickly tells you whether the time is being spent in a Retrieve, Commit, sub-microflow, or somewhere else. Mendix documents this approach under Microflow Time Stamps and also mentions the TimeMeasureStart / TimeMeasureEnd Java actions from Community Commons.

Once you know that a Retrieve/Commit is the bottleneck, you can use the runtime's slow query logging.


Set the runtime custom setting:

LogMinDurationQuery = 500

for example, temporarily while troubleshooting.

This causes queries taking longer than the configured number of milliseconds to be logged by the ConnectionBus_Queries log node. The default is 10000 ms. If you set ConnectionBus_Queries to TRACE, Mendix can provide additional information around the query, which can help you trace it back to the originating operation.

So you don't need to connect directly to PostgreSQL/SQL Server just to identify the slow Mendix query.


I would troubleshoot it in this order:

  1. Measure the microflow to find the slow activity.
  2. If it is a Retrieve/Commit, enable LogMinDurationQuery.
  3. Check the application logs for entries containing:
Query executed in
  1. Identify the entity/query involved.
  2. Then check the corresponding XPath, security XPath, associations and indexes.
  3. Also check whether the Retrieve is returning a large number of objects or is being executed repeatedly inside a loop.

Mendix specifically lists sub-optimal XPath, complex security XPath, missing indexes, calculated attributes and retrieving too many objects as common causes of slow database retrieves.

One thing I would avoid is enabling very verbose query/plan logging in production for a long period. In particular, DataStorage_QueryPlan has a large performance impact and Mendix explicitly recommends not enabling it in production.


If you're on Mendix 10.18+ and your deployment environment supports it, another option is OpenTelemetry tracing. Mendix can generate spans for frontend requests, microflows, retrieves, commits, deletes, loops and sub-microflows, which can give you a much better picture of where the request is spending its time.


So in your case, I would not start with direct database access or AI analysis. First capture the microflow timing + ConnectionBus_Queries logs. Once you have the slow query/log entry, you can determine whether the actual problem is XPath, security, indexing, number of retrieved objects, or repeated execution.


This should give you enough information to pinpoint the bottleneck without needing direct DB access.

answered