12.5/12.6 considerably slower than 12.4 when using prepared procedure statements

[JDBC-0]

We upgraded from 12.4.1 (over 12.6.1, 12.6.2 that we skipped due to bugs) to 12.6.3 ... the bugs seemed to solved but the driver is considerably slower that our last "production ready 12.4.1"
resulting in twice the duration for the database parts of our applications!

As these results in hours longer processings, we had to revert to 12.4.1. What can be the reasons nce of the 12.6 this extrem slower performance?

We run our test several times for each different driver version - just by replacing the *,jar and *.dll (x64) file the duration spans are as follows:

V 12.4.1 : 00:42 - 00:50
V 12.4.2 : 00:49 - 00:54
V 12.5.0 : 01:35 - 01:47
V 12.6.0 : 01:40 - 01:47
V 12.6.3 : 01:45 - 02:02

As you can see, starting since driver V 12.5.0, the execution times more than doubled!
(Windows 10, Java 17 LTS)

[Jeffery-Wasty]

Hi @JDBC-0,

Do you have a repro for us to reproduce the issue on our end? If not, are you able to tell us how you achieved these results? From our internal testing, JDBC performance has remained consistent across the last few versions, so we are curious what is being done differently in the situation you describe.

[JDBC-0]

As I described above: we triggered some processing in our big application to have a test case that is not too short and not too long and isolated 1 task that takes about 1 Minute. We repeated the exact same test 5 times (warming up, caches, etc.) and ended up with a minimum and maximum duration time.

We executed the exact same test in the exact same environment again and again by just stopping everthing, exchange the driver files (*.jar, *.dll) and started our test again 5 times (1st result thrown away). Same for different driver versions. Also reverted back and forth between driver versions with consistent results. In the end we got:

V 12.4.1 : 00:42 - 00:50
V 12.4.2 : 00:49 - 00:54
V 12.5.0 : 01:35 - 01:47
V 12.6.0 : 01:40 - 01:47
V 12.6.3 : 01:45 - 02:02

and a clear indication that the runtime since V 12.5.0 more than doubled! (Switchuing back tu 12.4.2 ... old results with half the execution time).

This is a process in Java that does heavy calculations, some database calls and in the end it spans several threads that each saves results into the database with their own separat database connection (each storing data in its own exclusive table). The storage phase is some kind of DELETE + INSERT and is done with prepared statements (of database stored procedure) that are called in batches (of 1000).

So, perhaps there were changes in the driver that slowed down prepared statements and/or batch executions of such prepared statements.

We switched back to 12.4.1 and our big processes went back to normal execution times.

[Jeffery-Wasty]

Ok, thank you for the additional information. Are you able to share with us this test case that you ran?

Looking at what you are running, and when the issue started (12.5.0). I think the culprit might be the changes to execute stored procedures directly. In this case, can you try running the same tests you ran for 12.5/12.6 but with useFlexibleCallableStatements set to false?

[JDBC-0]

Thanks for the hint "useFlexibleCallableStatements" ... I will be on cvacation now, but will get back latzer.

[Jeffery-Wasty]

Have you had a chance to test with the connection string option change? One other thing you can try is running this custom version of the 12.5 driver with the changes for callable statements removed.

without flex calls.zip

[JDBC-0]

Now, that's interesting:

12.5.0 preview : 01:39 - 01:48
12.6.3 + useFlexibleCallableStatements=false : 01:43 - 01:49
12.6.3 + useFlexibleCallableStatements=true: 01:37 - 01:50
your custom 12.5 + useFlexibleCallableStatements=false : 00:41 - 00:44

=> your custom 12.5 is back to old performance, but 12.6.3 + useFlexibleCallableStatements is still twice as slow ... !

BTW: we always use column index to set JDBC values - not column names.

[Jeffery-Wasty]

Thanks. It looks like there is a perf issue with the flexible callable statements feature that was added in 12.5.0. Unfortunately, we don't seem to be able to detect this (else it would have been resolved before release). Do you have a repro that you can share with us that produces the results mentioned above?

[JDBC-0]

I'm sorry, this is integrated in a bigger application. It saves thousands of table rows in 5 threads for 5 destination tables with 20 to 80 columns each table with JDBC batches of 1000 rows per batch.

If it's a problem with these "flexible callable statements", why does it still occur if useFlexibleCallableStatements = false is set? I would expect old performance behaviour if this flag is set to false .... ?

[Jeffery-Wasty]

I'll have to look into this more to see how this is the case. Perhaps there is some part that is not disabled when the connection string property is set to false. Regardless, the custom version of the driver I sent you was only missing the above feature, so it only makes sense that this is what is causing the performance issues.

[JDBC-0]

Yes. And if the performance problem just occurs for these "flexible callable statement" and we wouldn't need them (as we always set JDBC values by index number not by name), it would be sufficient to get useFlexibleCallableStatements=false working in a way that the old behaviour (and therefore performance) is triggered.

So I hope, that this flag does not cover all of the new code, yet. If you have fixed the scope/coverage of the flag, just send me a new custom version and I will test it with this flag on and off.