Hi,
A large performance gap between Mendix Cloud and an on-premise PostgreSQL setup is not unusual, especially right after a migration from Oracle. In most cases the cause is not the Mendix application itself but the surrounding infrastructure and database configuration.
A few areas are worth checking.
First, make sure the database is located on the same network segment as the Mendix runtime. Even small latency between the runtime and PostgreSQL can significantly impact Mendix because the platform executes many short queries rather than a few long ones. If the runtime and database are on separate VMs or networks, this can easily explain a large slowdown.
Second, check the disk performance of the PostgreSQL server. Mendix workloads are very I/O intensive (especially imports and batch processing). The Mendix Cloud environments run on high-performance SSD storage. If your on-premise VM uses slower disks or shared storage, database I/O can quickly become the bottleneck.
Third, review the PostgreSQL configuration. The default settings are usually conservative and not ideal for Mendix workloads. In particular, parameters such as shared_buffers, effective_cache_size, work_mem, and maintenance_work_mem should be tuned according to the available RAM. If PostgreSQL is running with default values, performance can be significantly lower than expected.
It is also worth checking the connection pool settings in Mendix. The runtime relies heavily on database connections, and if the pool size is too small or constrained by the VM resources, throughput may drop during heavy operations like imports.
Finally, enabling query logging or slow query logging in PostgreSQL can help identify whether the delay is happening in the database itself or before the query reaches the database (for example due to network or I/O).
In practice, the most common causes for the kind of difference you describe are network latency between the runtime and database, slower disk I/O on the on-premise VM, or PostgreSQL running with default configuration values that are not tuned for the available hardware.
Have a lovely day Dan, :)
From what I’ve seen so far, even when Cloud and On-Premise environments have similar resources, Mendix Cloud often performs better. One reason is that in Cloud environments the runtime, infrastructure and database are optimized to work together, so you usually avoid additional network or infrastructure latency that can happen in on-prem setups.
Because of this, on-premise environments sometimes need more resources than the Cloud environment to reach a similar performance level.
Another thing worth checking is the logging configuration. In several cases performance issues were caused by a high log verbosity level defined in the deployment YAML or environment configuration. If the runtime is running with INFO or DEBUG level logs, it can introduce noticeable overhead. In many production environments the recommended default is ERROR level logging unless detailed tracing is required.
That said, the most practical first step is usually to monitor the infrastructure metrics together with your platform or infrastructure team. In particular, it helps to analyze:
Once you have these metrics, it becomes much easier to identify whether the bottleneck is coming from the runtime, database, network, or storage layer, and then build a targeted action plan.
If this resolves your issue, please mark the answer as accepted so it can help others in the community as well.
Hi,
Thanks a lot for your quick answers.
We are investigating the performance issues during an Excel import process (hundreds of rows) on our on-premise environment. We have gathered the following technical evidence to help you identify the root cause.
1. JVM Heap Size configuration conflict Despite our configuration of the environment variable JAVA_TOOL_OPTIONS to 2Go (which is detected), the logs reveal that the Java Heap Size does not exceed 512 MB.
Runtime flags observed: -XX:CICompilerCount=2 -XX:CompressedClassSpaceSize=218103808 -XX:InitialHeapSize=536870912 -XX:MaxHeapSize=536870912 -XX:MaxMetaspaceSize=268435456 -XX:MaxNewSize=178913280 -XX:MinHeapDeltaBytes=196608 -XX:MinHeapSize=536870912 -XX:NewSize=178913280 -XX:NonNMethodCodeHeapSize=5826188 -XX:NonProfiledCodeHeapSize=122916026 -XX:OldSize=357957632 **-XX:OnError=/opt/mendix/build/.local/scripts/on_error.sh** **-XX:OnOutOfMemoryError=/opt/mendix/build/.local/scripts/on_out_of_memory_error.sh** -XX:ProfiledCodeHeapSize=122916026 -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:SoftMaxHeapSize=536870912 -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseSerialGC
Picked up JAVA_TOOL_OPTIONS: -Xms1g -Xmx2g
A jcmd thread dump confirms the following values:
Additionally, a generated file named java param.txt shows: "Picked up JAVA_TOOL_OPTIONS: -Xms2g -Xmx4g -XX:MaxMetaspaceSize=2048m"
We compared this with the Mendix Cloud environment. On the JVM Object Heap graph in the Cloud, we noticed it also uses only 512 MB, yet the performance is significantly better. We are questioning if this parameter is more impactful on-premise or if the application behavior should remain identical at ISO-values.
2. Suspicious Infrastructure Logs We observed the following command line in our infrastructure logs, where specific flags seem to override our settings: opt/mendix/build/.local/bin/java -Dfile.encoding=UTF-8 -Djava.io.tmpdir=opt/mendix/build/data/tmp **-XX:OnError=/opt/mendix/build/.local/scripts/on_error.sh** **-XX:OnOutOfMemoryError=/opt/mendix/build/.local/scripts/on_out_of_memory_error.sh** -DapplicationName=dockerexample -XXMaxMetaspaceSize=256M -Xmx512M -Xms512M -XX:+UseSerialGC -DMX_INSTALL_PATH=/opt/mendix/build/runtimes/10.24.1.74050 -jar /opt/mendix/build/runtimes/10.24.1.74050/runtime/launcher/runtimelauncher.jar /opt/mendix/build/
3. Database Performance Report (from our DBA) Our DBA has analyzed the PostgreSQL instance and reports optimal performance: "As agreed, please find attached the Excel file containing all SQL commands with an execution time of more than 1 ms, recorded this morning on the Mendix acceptance Postgres database. During the load tests, both the database and the dedicated server were under low load. We observed that SQL execution times during the test period did not exceed 35 ms for the longest ones. The average of all SQL processing during the reference period is: 1.5ms. In conclusion, the database operation is optimal and does not explain the observed slowdowns."
mendixr1.5ms4. Network Latency Our infrastructure team performed a connectivity test (nc) which does not show problematic latency: ys 0m0.002ssh-5.1$ time nc -zv 172.16.0.118 5432s real 0m0.004s user 0m0.000s sys 0m0.004s
Based on these elements, could you explain why the JVM remains locked at 512MB and if this discrepancy, combined with the triggered error scripts, could be the source of our performance issues compared to the Mendix Cloud?
Do you know which configuration is used on Mendix Cloud that could help us to see if we misconfigured something in our own network/database ?
If you need other things to answer precisely, I'll transfer them to our infra team.
Thanks,
Dan
Here is the complete log of the SQL queries made during our test :
https://1drv.ms/x/c/394ad273cd943ce3/IQDMGmgzeAL2RJtGzSQdxzvLATQaUS9SD-rYhwPUOWUzXn8?e=ohFZ0X
@Ahmet I've just tried to add it, but I don't see any gain on the performance when I try a new data import.
I will ask my Infratstructure collegues for logs to see if the parameter has been well applied.
Thanks for sharing the resources.
From the hardware specs, everything looks fine and fairly standard for this kind of workload. Nothing there would explain the heap being capped at 512 MB.
This still points to a runtime/container-level JVM configuration overriding the memory settings, rather than a hardware limitation. Especially since JAVA_TOOL_OPTIONS is detected but not effectively applied.
I would focus on checking:
These are typically where the override happens.
So at this point, it’s very likely something enforced at the platform or container level, not related to the underlying hardware.