Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of ronchalant@gmail.com designates
 209.85.221.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=F9KJBE032HuS4CE94eIJSJDw/ItuAX11MJSyoX4CBLuesmrtIdtnw8ECPoO9WLu8Pr
         0lr4Fz+Nnj0DMswbmDXCHoGL6QP3LNsqb9YStbTvgOkiq5FzfHBbcKM8JKAEApdpT8Du
         x8Sc2tVIjSZct8Z3/io2ahPgFzOOjQy4AEZ9g=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: Derby 10.3 Performance
From: Ronald Rudy <ronchalant@gmail.com>
In-Reply-To: <4BBF32DF.5040706@Sun.COM>
Date: Fri, 9 Apr 2010 10:17:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F89C0248-B6A0-4BFD-A4E4-F9F2EDADF55A@gmail.com>
References: <o2k679f019c1004090139w4f8ea9a9xc51f376f3fe117e6@mail.gmail.com>
 <4BBF32DF.5040706@Sun.COM>
To: "Derby Discussion" <derby-user@db.apache.org>

Memory is also a big consideration..=20

We've taken to running Derby using the network connector in a separate =
JVM entirely running as a daemon/service, which gives a number of =
benefits including exclusive rights to memory and the ability to connect =
to the database on a test or live system and run queries..

-Ron

On Apr 9, 2010, at 9:59:59 AM, Kristian Waagan wrote:

> On 09.04.2010 10:39, Rajesh Datla wrote:
>> Hi All,
>>            I like to know the performance utilization of  =
multi-processors on a machine by Derby 10.3. Does Derby 10.3 utilize all =
CPU's on 8 CPU machine?.
>>=20
>=20
> Hi Rajesh,
>=20
> I cannot give you any hard numbers for 10.3, but I have some general =
comments. Hopefully someone else can pitch in with more details.
>=20
> First, a fair bit of performance / scalability work has been done =
since 10.3. The community is in the process of preparing for the 10.6 =
release [1]. I would strongly suggest you use a newer release if =
possible.
>=20
> Further, how much of the CPU Derby can utilize depends heavliy on the =
load, with factors such as:
> - number of concurrent connections / queries
> - data contention
> - access pattern
> - IO subsystem (plus read/write ratio and page cache tuning )
>=20
> The Derby engine is multi-threaded and should be able to use the =
available CPUs when / if required. To find out the utilization rate you =
have to run a test with your app / load.
> Note that a single query will only use a single CPU / core.
>=20
> I have run an industry standard benchmark on a 32-core machine, and =
Derby is able to utilize the CPUs fairly well with that specific load =
and configuration (75+%).
> I have also seen syntetic benchmarks utilizing around 99% of the CPU =
(all data in memory, read only, no data contention), but I doubt you'll =
manage that in a real-world app :)
> And finally, Derby has to use the CPUs for something useful as well - =
I'd recommend a load test to see if Derby fulfills your requirements =
(then you can come back to the list and ask questions if you see =
unexpected results).
>=20
>=20
> Regards,
> --=20
> Kristian
>=20
> [1] http://wiki.apache.org/db-derby/DerbyTenSixOneRelease
>=20
>> Regards
>> Raj=20
>=20
>=20