db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Created: (DERBY-646) In-memory backend storage support
Date Sat, 29 Oct 2005 15:50:45 GMT
I am not sure I understand your question about network client/server and
Storage factory.  The Network layer is way above the StorageFactory
layer, so any change you make that makes an embedded client run in 
memory will automatically also be used if you access it using the 
network server interfaces (the in memory portion will always be on the
server side of the client/server interface).

Your numbers don't surprise me if your disk is not really supporting
synchronous I/O for log and data.  It may also be interesting to compare
your implementation numbers with running the existing server under
durability=test mode, especially if you ever figure out how to get your
disk to allow you to sync the log file.

The areas that are going to cause Derby to go slow:
o sync of log file at commit time (write cache enabled disk disables 
this sync)
o sync of data files at checkpoint time (write cache disables this sync)
o sync of data files when db cache gets full (write cache disables, for
   fair comparison you should make cache as big as database if you want 
to compare with your in memory implementation)
o read of uncached data from disk into cache - I guess this never 
happens in your implementation as all data has to come about from updates.

Stephen Fitch wrote:
> Hi Norbert,
> 
> I have it working in the trunk embedded client in gentoo linux under jdk 
> 1.4.2.08 but it should theoretically run under jdk 1.3.1 and any recent 
> release of derby. However, as far as I can tell the network 
> client/server doesn't support alternate implementations of 
> StorageFactory.  I'm still trying to track down if this is the case.  If 
> it is, another connection URL attribute may have to be added for 
> in-memory to work on the network side of things.
> 
> I'm having issues trying to test the performance as well since I'm 
> competing with derby's page cache, java.nio's and my hard drive write 
> cache (which I can't seem to turn off).
> 
> *VERY* preliminary numbers indicate a 10-20% performance increase on 
> inserts which is well below my expectations.  I'm going to code up some 
> tests for other operations today though.
> 
> If anyone's interested in trying the code out or going over it to look 
> for areas of improvement it would be much appreciated.
> 
> I suppose the best way to distro it would to email a svn diff patch and 
> source code for the new classes to the mailing list? I'm not looking to 
> get it added to svn though, as it still needs work.
> 
> Regards,
> 
> 
> 
> 
> Stephen Fitch
> Acadia University
> 
> 
> 
> 
> 
> 
> 
> 
> Toth-Gati Norbert wrote:
> 
>> Hi Stephen,
>>
>> So now this means the support for in-memory storage is completed.
>> I will give it a try. But glad you finally got to the end. Good job!
>>
>> Regards,
>>     Norbert
>>
>> ----- Original Message ----- From: "Stephen Fitch (JIRA)" 
>> <derby-dev@db.apache.org>
>> To: <derby-dev@db.apache.org>
>> Sent: Tuesday, October 25, 2005 8:33 PM
>> Subject: [jira] Created: (DERBY-646) In-memory backend storage support
>>
>>
>>> In-memory backend storage support
>>> ---------------------------------
>>>
>>>         Key: DERBY-646
>>>         URL: http://issues.apache.org/jira/browse/DERBY-646
>>>     Project: Derby
>>>        Type: New Feature
>>>  Components: Store
>>> Environment: All
>>>    Reporter: Stephen Fitch
>>>
>>>
>>> To allow creation and modification of databases in-memory without 
>>> requiring disk access or space to store the database.
>>>
>>> -- 
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the administrators:
>>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see:
>>>   http://www.atlassian.com/software/jira
>>>
>>
>>
> 
> 


Mime
View raw message