db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Derby 10.3 Performance
Date Fri, 09 Apr 2010 15:44:47 GMT
On09.04.2010 16:17, Ronald Rudy wrote:
> Memory is also a big consideration..

Hi Ronald,

Yes, it is; the page cache size, garbage collection and "memory for 
other Derby stuff".
Since Derby's page cache is defined in number of pages, which can vary 
in size, it's difficult to set a hard limit on the memory usage.

> 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..

I understand your point about exclusive memory rights. Getting the 
balance right with Derby embedded inside the other app(s) can be tricky 
in some cases.

Regarding your second point, are you aware of the "embedded server" mode?
This is where you have your main app connecting to Derby using the 
embedded driver, and then you can start up a network server (permanent 
or temporary) as well. Doing this requires a little bit of coding, or 
setting a property when starting the main app (or rather before loading 
the Derby driver).


> -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

View raw message