Hello,
We have multiple customers reporting performance issues with the recent versions of the JTOpen400 JDBC driver when used from Talend. Issue seems to be independent from Java (happens with both 8 and 11) , we had both Linux / Windows complaints.
We tried to investigate as much as possible and come to the following conclusion:
Without changing any code from our side just the JDBC driver we can see a performance issue.
The different JDBC drivers have no difference when examined via JFR.
The performance difference is 20 seconds for small amount of data.
As it seems that we're simply waiting on the network we also collected network packets.
After analyzing these packets it seems that the older drivers send 65k packets while the new one does 1k. This results in the total packets between the client-server increase from 101/40 packets to 1534/1028 packets.
Drivers used in the test:
Latest JTOpen (11.0)
jt400_V5R2
Is there a JDBC parameter/property we should configure to force the old behavior?
Regards,
Balázs
I wasn't able to add multiple attachments easily, but here's the new version:
Try setting the block size property
"block size" Specifies the block size (in kilobytes) to retrieve from the system and cache on the client. This property has no effect unless the "block criteria" property is non-zero. Larger block sizes reduce the frequency of communication to the system, and therefore may increase performance.
https://jt400.sourceforge.net/doc/com/ibm/as400/access/doc-files/JDBCProperties.html
Hello John,
Thanks for the quick response. We've asked our customer to validate this but still waiting for feedback.
Will keep you posted.
Hello John,
Block size does affect the Read Performance. By setting it to 512 we can see it's faster. (I was able to go up to 1000row/sec from 500row/sec)
However the write performance is still not good. Meanwhile I got access to a system.
We're using Prepared Statements.
I tried with a 10/100 batch size.
Here's my setting:
block size=512;send buffer size=512;toolbox trace=datastream;
By enabling the toolbox trace I can see that we're sending data record by record and waiting for a response from the server.
In fact it seems that there's a lot of null values. I created my tables with type VARCHAR(128) but the drier behaves like CHAR(128)
Attached a snippet of the output.
Regards,
Balázs
Hello John,
Happy new year!
Is there any other files / information we should provide?
Regards,
Balázs
Can you provide traces of running with the old driver and the new driver so that I can compare them? Can you also use toolbox trace=all?
Hello John,
Please find the log files attached.
The old driver generates a lot smaller logs (13mb vs 26mb)
advParam=block size\=512;send buffer size\=512;toolbox trace\=all;data compression\=true
It looks like the application is requesting that auto generated keys are to be returned by the insert statement. The JTOpen 5.4 driver did not always correctly return generated keys. If generated keys are not retrieved by the application, can the prepare of the insert statement be changed to not request generated keys?
In the JTOpen 5.4 driver the inserts are batched. In the recent drivers, the inserts cannot be batched because the return of auto generated keys was requested.
The *SQLGENCOLUMNS is how the generated keys are returned.
Hello John,
Thank you for the insight, indeed we have this:
I’ll test it tomorrow and report it back to you.
Balázs Gunics
Product Manager, Talendhttp://www.talend.com/
From: bugs@jt400.p.re.sourceforge.net bugs@jt400.p.re.sourceforge.net On Behalf Of John Eberhard
Sent: Thursday, January 12, 2023 7:19 PM
To: [jt400:bugs] 469@bugs.jt400.p.re.sourceforge.net
Subject: [jt400:bugs] #469 Performance Issues due to Packet Size
It looks like the application is requesting that auto generated keys are to be returned by the insert statement. The JTOpen 5. 4 driver did not always correctly return generated keys. If generated keys are not retrieved by the application, can
It looks like the application is requesting that auto generated keys are to be returned by the insert statement. The JTOpen 5.4 driver did not always correctly return generated keys. If generated keys are not retrieved by the application, can the prepare of the insert statement be changed to not request generated keys?
In the JTOpen 5.4 driver the inserts are batched. In the recent drivers, the inserts cannot be batched because the return of auto generated keys was requested.
Details:
Tracepoint in JTOpen 5.4: Begin batching via server-side with 100 rows..
Tracepoint in JTOpen 11.0: Begin batching via client-side multiple executes..
Details:
Tracepoint in JTOpen 5.4: Prepared STMT0001*, SQL Statement -->[INSERT INTO BGUNICS_TEST (newColumn,newColumn1,newColumn2,newColumn3,newColumn4) VALUES (?,?,?,?,?)].
Tracepoint in JTOpen 11.0: Prepared STMT0001*, SQL Statement -->[SELECT *SQLGENCOLUMNS FROM NEW TABLE(INSERT INTO BGUNICS_TEST (newColumn,newColumn1,newColumn2,newColumn3,newColumn4) VALUES (?,?,?,?,?))].
The *SQLGENCOLUMNS is how the generated keys are returned.
[bugs:#469]https://urldefense.com/v3/__https:/sourceforge.net/p/jt400/bugs/469/__;!!CiXD_PY!WFxwc8RhVzGxcmFE4GSOXRHXOa0en4GvYl9UPHic5cJ7L24IMupXZ-6ikJNzbMHnUrcIzaVWmrRNGK_morgspxWsEA$ Performance Issues due to Packet Size
Status: pending
Group: JDBC
Created: Mon Oct 24, 2022 01:57 PM UTC by Balázs Gunics
Last Updated: Thu Jan 12, 2023 11:19 AM UTC
Owner: John Eberhard
Attachments:
Hello,
We have multiple customers reporting performance issues with the recent versions of the JTOpen400 JDBC driver when used from Talend. Issue seems to be independent from Java (happens with both 8 and 11) , we had both Linux / Windows complaints.
We tried to investigate as much as possible and come to the following conclusion:
Without changing any code from our side just the JDBC driver we can see a performance issue.
The different JDBC drivers have no difference when examined via JFR.
The performance difference is 20 seconds for small amount of data.
As it seems that we're simply waiting on the network we also collected network packets.
After analyzing these packets it seems that the older drivers send 65k packets while the new one does 1k. This results in the total packets between the client-server increase from 101/40 packets to 1534/1028 packets.
Drivers used in the test:
Latest JTOpen (11.0)
jt400_V5R2
Is there a JDBC parameter/property we should configure to force the old behavior?
Regards,
Balázs
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jt400/bugs/469/https://urldefense.com/v3/__https:/sourceforge.net/p/jt400/bugs/469/__;!!CiXD_PY!WFxwc8RhVzGxcmFE4GSOXRHXOa0en4GvYl9UPHic5cJ7L24IMupXZ-6ikJNzbMHnUrcIzaVWmrRNGK_morgspxWsEA$
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/https://urldefense.com/v3/__https:/sourceforge.net/auth/subscriptions/__;!!CiXD_PY!WFxwc8RhVzGxcmFE4GSOXRHXOa0en4GvYl9UPHic5cJ7L24IMupXZ-6ikJNzbMHnUrcIzaVWmrRNGK_morgs2DHBXg$
As a recipient of an email from Talend, your contact personal data will be on our systems. Please see our privacy notice. https://www.talend.com/privacy/
Related
Bugs:
#469Hello John,
Yes removing the return generated keys increases the performance greatly.
pstmt_<%=cid %> = conn_<%=cid%>.prepareStatement(insert_<%=cid%>, java.sql.Statement.RETURN_GENERATED_KEYS);
Thank you for your help!