db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Rudy <ronchal...@gmail.com>
Subject Re: Derby 10.3 Performance
Date Fri, 09 Apr 2010 14:17:06 GMT
Memory is also a big consideration.. 

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?.
>> 
> 
> Hi Rajesh,
> 
> 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.
> 
> 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.
> 
> 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 )
> 
> 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.
> 
> 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).
> 
> 
> Regards,
> -- 
> Kristian
> 
> [1] http://wiki.apache.org/db-derby/DerbyTenSixOneRelease
> 
>> Regards
>> Raj 
> 
> 


Mime
View raw message