[ http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12363652 ]
Tomohito Nakayama commented on DERBY-326: ----------------------------------------- I got the result of long run. before patch: ===================================================== TestRun =1 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Populating data Data length inserted into clob = 537638 Avg time for test[1 ]=20912.137ms ===================================================== ===================================================== TestRun =2 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[2 ]=20772.027ms ===================================================== ===================================================== TestRun =3 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[3 ]=20782.217ms ===================================================== ===================================================== TestRun =4 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[4 ]=20768.951ms ===================================================== Throw away the result of the first run ================OUTPUT============================= Avg time taken to read 100rows+ (ignore first run )=20774ms after patch: ===================================================== TestRun =1 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Populating data Data length inserted into clob = 537638 Avg time for test[1 ]=20826.22ms ===================================================== ===================================================== TestRun =2 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[2 ]=20934.18ms ===================================================== ===================================================== TestRun =3 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[3 ]=20935.023ms ===================================================== ===================================================== TestRun =4 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[4 ]=20943.951ms ===================================================== Throw away the result of the first run ================OUTPUT============================= Avg time taken to read 100rows+ (ignore first run )=20937ms The results of long run show that there exists a little fall in the speed after patch against short run. I think this may be due to "too many short lived objects" in ReEncodedInputStream which Sunitha and Kathey talked about. I will try the long run again after revision. > Improve streaming of large objects for network server and client > ---------------------------------------------------------------- > > Key: DERBY-326 > URL: http://issues.apache.org/jira/browse/DERBY-326 > Project: Derby > Type: Improvement > Components: Network Server, Network Client, Performance > Reporter: Kathey Marsden > Assignee: Tomohito Nakayama > Attachments: ClobTest.zip, DERBY-326.patch, DERBY-326_2.patch, > DERBY-326_3.patch, DERBY-326_4.patch, DERBY-326_5.patch, > DERBY-326_5_indented.patch > > Currently the stream writing methods in network server and client require a > length parameter. This means that we have to get the length of the stream > before sending it. For example in network server in EXTDTAInputStream we have > to use getString and getbytes() instead of getCharacterStream and > getBinaryStream so that we can get the length. > SQLAM Level 7 provides for the enhanced LOB processing to allow streaming > without indicating the length, so, the writeScalarStream methods in > network server DDMWriter.java and network client Request.java can be changed > to not require a length. > Code inspection of these methods seems to indicate that while the length is > never written it is used heavily in generating the DSS. One strange thing is > that it appears on error, the stream is padded out to full length with zeros, > but an actual exception is never sent. Basically I think perhaps these > methods need to be rewritten from scratch based on the spec requirements for > lobs. > After the writeScalarStream methods have been changed, then EXTDAInputStream > can be changed to properly stream LOBS. See TODO tags in this file for more > info. I am guessing similar optimizations available in the client as well, > but am not sure where that code is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
