db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ahlinder <jonas.ahlin...@digitalroute.com>
Subject RE: performance issue
Date Mon, 20 Oct 2008 08:29:44 GMT
Hello all involved.

The growing index problem is "solved", running compress_table sequentially ( not inplace_compress_table
as it didn't do much of anything ) does shrink the filesize on disk.
However it takes way too long to do.
We will have to solve this in some entirely different manner.

The performance issue is still open, although I have a theory that I would be very happy if
you could smash holes in or agree with.
My theory is that java on windows isnt 100% durable when making diskcommits.
That there is a cache or buffer somwhere ( os/controller/disk ) that doesn't get flushed right
away when doing commit in derby ( sync is what derby does afaik ), and that's the reason it's
a lot faster, and linux/solaris gives a more realistic image of transaction performance.


-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
Sent: Sunday, October 19, 2008 11:10 PM
To: Derby Discussion
Subject: Re: performance issue

For something that large, it's probably best to file a JIRA and upload
the code as a patch. You can decide whether the uploaded code can be
licensed under the Apache license (e.g. if you don't mind it becoming
a test case) or not.


On Oct 19, 2008, at 3:17 AM, Jonas Ahlinder wrote:

> We would be willing to share the code.
> What would be the best way to do this ?
> Theres 869 lines of code, do i just paste it in a mail to the list ?
> ________________________________________
> From: Bryan Pendleton [bpendleton@amberpoint.com]
> Sent: Thursday, October 16, 2008 8:49 PM
> To: Derby Discussion
> Subject: Re: performance issue
>> I have tried running more threads, and it does seem to give
>> better performance, but the current state of the client
>> doesnt really allow for reliable testresults.
>> With autocommit on, and with the disk running 100% usage
>> ( and quite a bit of wait queue at least on Linux ) do
>> you think multiple threads will really help ?
> Yes.
> But, before changing your benchmark, it seems better to try
> to understand the results you are getting.
> Are you willing/able to share your benchmark with the community?
> thanks,
> bryan

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message