Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 67128 invoked from network); 10 Jan 2008 16:33:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Jan 2008 16:33:56 -0000 Received: (qmail 52610 invoked by uid 500); 10 Jan 2008 16:33:45 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 52577 invoked by uid 500); 10 Jan 2008 16:33:45 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 52340 invoked by uid 99); 10 Jan 2008 16:33:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Jan 2008 08:33:44 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Jan 2008 16:33:28 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 167E3714233 for ; Thu, 10 Jan 2008 08:33:34 -0800 (PST) Message-ID: <20097230.1199982814089.JavaMail.jira@brutus> Date: Thu, 10 Jan 2008 08:33:34 -0800 (PST) From: "Timothy Graf (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-3312) Local Network Server Performance In-Reply-To: <10468865.1199928633988.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557689#action_12557689 ] Timothy Graf commented on DERBY-3312: ------------------------------------- Yes, for our client retrieving records over the network is faster than one of our clients running on the same machine as our server. This symptom is only seen in versions 10.2.1.6 of Derby or higher. If I revert back to version 10.1.3.1 of Derby we do not see the difference in performance for a client run locally versus over the network. Our clients use JDBC to retrieve the entire list of records from our only table in the database and yes, we do limit the maximum number of records to 500. I'll reply again with the additional information you requested. Thanks very much for your reply. > Local Network Server Performance > -------------------------------- > > Key: DERBY-3312 > URL: https://issues.apache.org/jira/browse/DERBY-3312 > Project: Derby > Issue Type: Bug > Components: Network Server > 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 > > 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.