db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Date Fri, 11 Aug 2006 00:14:07 GMT
Oh, one more thing, the database I have heard us compared with is HSQL. 
  Folks don't expect us to be equivalent, given that HSQL is in-memory, 
but they do complain that the difference is just a little too much, from 
basically instantaneous to 10s of seconds...

The use cases I have heard of are unit testing (I think we've even 
complained about this, our way of solving it is reusing the same 
database :)), and during development where you're constantly rebooting 
the server that has the database embedded.  Another area of concern for 
me is when the database is being created in a browser-embedded 
application.  Java already has a bad rap for slow boot-up time in those 
environments...

David

Mike Matrigali wrote:
> I would like to participate in the discussion on this, let me know what
> you prefer (list, jira, wiki).  As dan said I believe there are many
> parts to this issue and would like to see them broken down.  I also do
> think there is a perception issue also and not quite sure how to
> address it, do the db's we are being compared to allow create and
> connect in the same jdbc statement?
> 
> My initial take is:
> 1) pick a platform and do some measurements, need to know if the 
> platform properly sync's the disk when asked.
> 2) compare creating empty database with copying an empty database
>    template from a jar file, with copying an empty database template
>    from disk.  I do not think derby should go to template based
>    approach for creating database.  I also witnessed a number of 
> bugs/harder to maintain code in 2 previous companies I worked at which 
> used this approach, where the current approach has been maintainable 
> from the start in derby.  I do think that if copying from a template is
> faster, then we should just document to users how/why they should do it
> if creating a db is a critical performance point for their application.
> Derby already fully supports this (at least from disk), it is exactly
> what restoring from a backup does and we already support restoring a 
> single db to multiple other data locations.
> 3) break up the "startup" cost issue into measureable understandable
>    pieces, as dan laid out -- just to make sure we are fixing the
>    right problem.  I really want to separate "startup" issues from
>    creating a new db issues.
> 
> David Van Couvering (JIRA) wrote:
>>      [ http://issues.apache.org/jira/browse/DERBY-1664?page=all ]
>>
>> David Van Couvering reassigned DERBY-1664:
>> ------------------------------------------
>>
>>     Assignee: David Van Couvering
>>
>>
>>> Derby startup time is too slow
>>> ------------------------------
>>>
>>>                Key: DERBY-1664
>>>                URL: http://issues.apache.org/jira/browse/DERBY-1664
>>>            Project: Derby
>>>         Issue Type: Improvement
>>>         Components: Store
>>>           Reporter: David Van Couvering
>>>        Assigned To: David Van Couvering
>>>            Fix For: 10.2.0.0
>>>
>>>
>>> I know it's hard to measure what "too slow" is, but this is a common 
>>> complaint and this affects overall perception of Derby.  This appears 
>>> to be related to another common complaint that it takes too long to 
>>> create tables.  I am marking this as Urgent because of the impact it 
>>> has to Derby perception and the fact that the 10.2 release is going 
>>> to get such wide distribution through the Sun JDK.
>>> For background, see 
>>> http://www.nabble.com/Startup-time-tf2012748.html#a5531684
>>
>>
> 

Mime
View raw message