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:11:09 GMT
Hi, Mike.  Thanks for wanting to participate.  My first step I was 
planning to do was to do some measurements, as you suggested.

I was going to start with my own machine, which is a laptop running 
Solaris x86.  But I suspect a lot of folks care about XP and Linux.  I 
can create a test and we can run it on different machines and see what 
the variance is.

I was thinking of doing a test that measures startup time with creating 
a new db and using an existing one as the first step.  I was then going 
to refine from there.

Dumb sysadmin question: on Solaris, XP, and Linux, how do you find out 
if your system is syncing to disk or not?

Thanks,

David

P.S. I'm not prepared to have the discussion about copying from a model 
database at this time.  Let's just first find out what's going on...

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