Higher database load after migration from Cuba to Jmix1

Support
#1

Hi all,

beginning this year we migrated an application from Cuba to Jmix. We used the migration-tool to update the database. After we were done making al the necessary code changes, our team noticed that database loads seemed to be significantly higher after the migration. At first we thought that this was because of additional features we had implemented around that time, but the more we investigated the more we come to the conclusion that somehow the database performance under Jmix is worse than under Cuba. But we don’t understand what is the reason for this. Do you have any pointers? Are there other teams who noticed the performance drop? Is there someting we could look into? Any tips?

Kind regards,
Bart

#2

Hi Bart,

We don’t have any particular known issues from the category “now this works noticeably worse than in CUBA”. So it’s hard to say what exactly you have faced.

How does it show?
Is it to many (more than expected) queries are executed or is it some kind of “general” performance?

What database do you use? Can you provide some details about your investigation?

If you manage to isolate the possible issue - “slow” use case, DB table(s) with slow access or anything else - that can be useful.

Regards,
Ivan

#3

Hi Ivan,
well, we have one application. We have quite a lot of instances of this application running on a cluster. Each with their own Tomcat-environment. They all use a Postgres database cluster. We got the impression that the total load of all these instances was about a factor 3 higher after the migration of the application from Cuba to Jmix1. At that time we were not to worried, because we had plenty free resources, but now we have even more instances of the application running and the cluster is getting overloaded so our infra-team wants to know why our application is using so much resources.
We are looking into two things:

  • Are there indexes missing, that were there in Cuba? Did the migration maybe remove indexes?
  • Did we maybe introduce performance-hogs in our fetchplan? We had to make quite a few changes to the fetchplan that was generated during migrartion to get our application to run.

But maybe there are other things to look into…
Bart

#5

Hi, Bart!

First of all, please provide us with your Jmix version. Our general advice is to use the latest version. Currently, it is 1.7.1 for Jmix 1.x or 2.6.2 for Jmix 2.x
Also you could use the pg_stat_statements module of PostgreSQL to find the most frequent or the most expensive queries.

Also you can use Jmix Micrometer metrics with our Grafana visualization. You can download it here GitHub - jmix-framework/jmix-grafana-dashboards To use it you should configure a monitoring environment with the Prometheus and Grafana services. Such visualization can give you information about sluggish screens or Data Loaders.

#6

Also you can check your FetchPlans. It is a very common problem, for example, not to specify some reference fields that are used in a DataGrid or in some logic. Such mistakes lead to the N+1 problem.

#7

Thanks for al your input. We dit find several problems in our code, that had a large impact on performance. After setting sql-log-level to ‘debug’ we found that jmix would query the database much more frequently than we had expected. The FetchPlans were indeed one of the culprits: we were missing several fields there. This also helped to find queries that benefitted from additional indexes. So ,als in all we are quite happy with the progress. There is more to do, but at least we now know it’s our own fault :slight_smile:
Kind reagrds,
Bart

1 Like
#8

Nice to hear that, Bart! An enabling the “DEBUG” log level for logging.level.eclipselink.logging.sql is also a good idea for the performance problems investigation.