efm2 plugin performance degradation in version 2.6.3

[rostasz-dynatrace]

Describe the bug

We've noticed significant performance degradation visible in HostMonitorServiceImpl.getMonitor method invocation, comparing to version 2.6.2. I'm attaching screens from profiler during our performance tests. The only difference in code is the aws jdbc wrapper version.

2.6.3

2.6.2

Blue bars and percentage indicates cpu usage during the tests.

Expected Behavior

No change in performance.

What plugins are used? What other connection properties were set?

wrapperPlugins: auroraConnectionTracker,readWriteSplitting,failover,efm2,iam
readerHostSelectorStrategy: roundRobin
maxConnectionAge: 60s
readOnlyByDefault: true

Current Behavior

Code works fine, but performs worse.

Reproduction Steps

Run code on version 2.6.3 and 2.6.2, observe timing of HostMonitorServiceImpl.getMonitor method.

Possible Solution

No response

Additional Information/Context

No response

The AWS Advanced JDBC Driver version used

2.6.3

JDK version used

openjdk 21.0.8 2025-07-15 LTS
OpenJDK Runtime Environment Temurin-21.0.8+9 (build 21.0.8+9-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.8+9 (build 21.0.8+9-LTS, mixed mode, sharing)

Operating System and version

Debian 12

[aaron-congo]

Hi @rostasz-dynatrace,

Thank you for reporting this issue. I have been unable to reproduce this problem so far. Are you able to provide a simple sample app that reproduces the problem? Also, can you please tell me which profiler you are using?

[rostasz-dynatrace]

Hi @aaron-congo,

Thanks to taking a look into that! We use Dynatrace to monitor / profile our applications which are running on k8s cluster. Unfortunately it will be not possible to share our current code and we have no resources to work on sample app reproducing it... But I am ready to answer any questions or provide more information about our configuration based on your request.

[aaron-congo]

Thanks for that info. Had a few questions:

1. Since you aren't able to provide a sample app, are you able to tell me generic info about what your performance tests do that may be triggering this? For example, how many connections are you spinning up, are the connections running concurrently, are your queries long-running/intensive or short or mixed? Any other unique behavior that I can try to replicate to trigger the issue?
2. Are you running against mysql or postgres?
3. Are you using Aurora or an RDS multi-az cluster or a single RDS instance?
4. How many database instances are in your database cluster?
5. Are you triggering failover during your performance tests?
6. Are you using connection pools? If so, which connection pools are you using, and what is your connection pool configuration?
7. I see you are using the read-write splitting plugin, how often are you switching between the writer/reader via calling Connection.setReadOnly?
8. Are you using Spring?

[rostasz-dynatrace]

1. We are using connection pooling. One connection is open for at most 60 seconds. The tests are running for around 2h, during that time number of open connections is constantly changing. In a peak there are around 180 open concurrent connections, but the single test scenario that seems to be impacted the most have around 75 concurrent connections open. Database is loaded with many short queries - 25 ms average response time for a single query on a most impacted test, and within that scenario only read operations are performed. Each query for a single user request might be performed on a different connection.
2. Postgress
3. Aurora
4. The data is available in multiple instances, but I would prefer to do not expose exact numbers.
5. No
6. Yes, pools for read-write and for read only. We use them and configure separately by a different components. I'm attaching here config for a component that is tested during a scenario where the slow down is visible the most.
   maxWaitForConnection: 3s validationInterval: 1s validationQuery: "SELECT 1" validationQueryTimeout: 1s initialSize: 2 minSize: 2 maxSize: 32 checkConnectionWhileIdle: true checkConnectionOnBorrow: true evictionInterval: 10s minIdleTime: 1 minute removeAbandoned: true maxConnectionAge: 60s readOnlyByDefault: true
7. It seems to be managed by the frameworks that we are using.
8. No, dropwizard + jdbi

[aaron-congo]

Thanks for that info, I believe I have been able to reproduce the problem and am currently working on a fix. I'll keep you updated.

[aaron-congo]

Hi @rostasz-dynatrace,

We have just merged in a fix. Could you kindly checkout our snapshot build and let us know if the issue still persists?

Thank you!

[rostasz-dynatrace]

Thanks @aaron-congo,
The issue is fixed. Works much better now!

[aaron-congo]

Hi @rostasz-dynatrace, just letting you know that we released the bug fix in 2.6.5, so I'll be closing the ticket now. Feel free to let us know if you encounter any other problems. Thanks!