[jira] Commented: (DERBY-3312) Local Network Server Performance degradation with 10.2 or later

["Kristian Waagan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644725#action_12644725 ] 

Kristian Waagan commented on DERBY-3312:
----------------------------------------

I started looking at Blob again, since Clob has some additional complexity.
I'm unable to see the performance degradation for the 10.2 versions with my Blob data (only 1 to 5 bytes long), but when I move to 10.3 it's there.
When moving to 10.3, the time it takes to run the repro increases 3-4 times.

I believe the performance degradation is caused by the introduction of locators, and more specifically the increased number of round-trips:
 a) We get the locator value (rs.next()).
 b) We access the server, using the locator value, to obtain the Blob length.
 c) We access the server, using the locator value, to fetch the Blob data.

I think round-trip b) can be removed most easily, but there are details that might make it harder to do.
With a hack I got the duration (fetching 15000 small Blobs) down from around 2100 ms to 1400 ms. The duration for 10.2 is just under 600 ms.

I think getting the current implementation down to the duration seen with 10.2 is impossible, due to the increased number of round-trips and the extra code for LOBs.
One could make Derby capable of using locators for only selected rows, and send the complete content where the Blob is small enough. This would increase the code complexity significantly.

On the other hand, I'm not sure this is an issue that should be fixed by Derby.  LOBs are intended to be used for large objects. Would using VARCHAR [length FOR BIT DATA] be better for situations like this?
My repro gets down to less than 25 ms (trunk) using this data type instead of BLOB. I think the reasons are reduced number of round-trips and prefetching.
Then the questions are, why is BLOB used is in this specific case and can it be replaced with VARCHAR length FOR BIT DATA?

> Local Network Server Performance degradation with 10.2 or later
> ---------------------------------------------------------------
>
>                 Key: DERBY-3312
>                 URL: https://issues.apache.org/jira/browse/DERBY-3312
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server, Performance
>    Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1
>         Environment: Intel x86 based server SuSE Linux Enterprise Server 10
> Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> Derby 10.3.2.1
>            Reporter: Timothy Graf
>         Attachments: LobPerf.java
>
>
> We have a Java based XML-RPC client/server product that incorporates an embedded Derby database and network server.  Our client uses the derby JDBC ndriver and network client to connect to the Derby Network Server.
> We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby code, because of other issues which seem to be resolved by moving to the latest Derby release.  We have a very simple database with a simple table.  This table does include BLOBs, however its size has not been an issue and we limit our records to 500.
> Since moving to the latest release of Derby, version 10.3.2.1, we noticed that our clients running on the same machine as our server take much longer to retrieve a list of records from the database.  Our clients running on a remote machine do not seem to have any performance issues when retrieving the same list of records.
> We start our Network Server in Java through the API so I don't think the Security Manager is the issue.  I read that performance could be affected by the Security Manager, but according to the Derby documentation, 
> "The Network Server will not attempt to install a security manager if you start the server from your application using the programmatic API ..."
> I tried going back several releases of Derby and the performance issue seems to go away when I run with version 10.1.3.1 of Derby.  However we see the same issue that we saw with Cloudscape in that we can not turn off connection logging.  We also had stability problems with the Network Server with Cloudscape.
> We would really prefer to use the latest Derby release however the performance issues are a sever limitation.  I thought that maybe this was a simple Network Server configuration issue however after researching this issue I have not found anything from a configuration standpoint that may help.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.