Performance degradation with Mendix 8

4
We're running a large application, large and complex database, concurrent minimal 100 users each day and several background processes using the process queue module. This application is started in Mendix 2.5 and has been upgraded every since. In Q2 2020 the application was migrated from the Mendix cloud V2 to the Mendix cloud V4. Everything was working fine with the required performance in Mendix 7. This week we've upgraded the application to Mendix 8. Unfortunately the performance has been degraded a lot. Background processes that has been running in Mendix 7 for 10 minutes, has go 50 minutes in Mendix 8. This a degradation of 5 times. I've noticed myself with other projects that are in Mendix 7.23 or higher has an issue with performance on long running functionalities. Somehow the transactions of an microflow grows which has a negative impact on the performance. Does anyone has experiencing the same problem and even better a solution? 
asked
2 answers
9

Did you try the custom runtime setting DataStorage.UseNewQueryHandler := false ? We had performance degradation going to Mendix 8 and this solved it

answered
2

We have had a similar issue, however for us it occurred when we upgrade from Mendix 6 to Mendix 7. We went through a very extensive performance testing phase to deliver results to Mendix that conclusively proved that the performance of Mendix 7 was worse than the performance of Mendix 6.

Mendix investigated this, and from their tests, they concluded that the performance of Mendix 6 and Mendix 7 were comparable, but that there had been a change to the process queue. Below is their response on this issue.

 

“I would like to give you an update on the investigation about this ticket. 
After analyzing the difference between Mx6 and Mx7 on multiple elements like web services, retrieves and microflow actions we're unable to explain the difference you are noticing between the modeler versions. 
After tracing what actually happens in the background we saw a big difference between Mx6 and Mx7. What was noticable were the big gaps in Mendix 7 between starting an action in the process queue and the process queue action actually being started.  In Mendix 6 this was milliseconds and in Mendix 7 this was multiple seconds (see image below)

After looking at the code of the process queue this pattern actually has a logical explenation. In Mendix 6 the process queue was designed that is constantly was looking for new queues to be started. This means that directly after using the 'Append New Action to Queue' a new transaction was started and the process was executed. This goes well in your case in Mendix 6 because you are using the 'Append New Action to Queue'  at the end of the microflow and use an 'End Transaction'. However in more cases this design brought bugs to apps. With this design using the 'Append New Action to Queue' at the beginning of a microflow would cause a new transaction to be started without the main microflow (and it's transaction) to be ended. This would cause objects not being available in the process queue. 
Because of the reason above, in Mendix 7 the design of the process queue was changed and the following code was added:

try {
        Thread.sleep(5000);

This will cause the process queue to check every 5 seconds if a new process can be started. In your experiment there are multiple process queue actions. If we add all the waiting times together we see that the runtime is actually waiting for processes to be started for 15 seconds. 

When changing this code to only wait 10 milliseconds we were able to reduce the duration of the experiment with 15 seconds. 
I would recommend using the newer version of the process queue because of multiple bugs being fixed in this version. If you however want to limit the time it takes to run the experiment/ this action you can also change the code yourself. The code can be found in the following path:
 

Project\javasource\processqueue\queuehandler”

answered