[ http://issues.apache.org/jira/browse/DERBY-326?page=all ]
Tomohito Nakayama updated DERBY-326:
------------------------------------
Attachment: ReEncodedInputStream.java.modifiedForLongRun
This is a result of long run with modification of ReEncodedInputStream.java not
to create buffer for each time.
Attached ReEncodedInputStream.java.modifiedForLongRun is ReEncodedInputStream
after the modification.
=====================================================
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 ]=20661.984ms
=====================================================
=====================================================
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 ]=20764.193ms
=====================================================
=====================================================
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 ]=20772.66ms
=====================================================
=====================================================
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 ]=20760.312ms
=====================================================
Throw away the result of the first run
================OUTPUT=============================
Avg time taken to read 100rows+ (ignore first run )=20765ms
I found that it is a little faster than before patch.
However not so much ...
> 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, ReEncodedInputStream.java.modifiedForLongRun
>
> 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
