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
