You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David Van Couvering (JIRA)" <de...@db.apache.org> on 2006/08/10 20:05:14 UTC
[jira] Created: (DERBY-1664) Derby startup time is too slow
Derby startup time is too slow
------------------------------
Key: DERBY-1664
URL: http://issues.apache.org/jira/browse/DERBY-1664
Project: Derby
Issue Type: Bug
Reporter: 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
--
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
Re: [jira] Created: (DERBY-1664) Derby startup time is too slow
Posted by Mike Matrigali <mi...@sbcglobal.net>.
this seems like an improvement request, not a bug.
David Van Couvering (JIRA) wrote:
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: http://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Bug
> Reporter: 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
>
[jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=comments#action_12427296 ]
David Van Couvering commented on DERBY-1664:
--------------------------------------------
Also this mail thread on derby-user is helpful
http://www.nabble.com/Startup-time-for-Derby-tf2012733.html#a5545202
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: http://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Bug
> Components: Store
> Reporter: 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
--
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
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by David Van Couvering <Da...@Sun.COM>.
Ah, yes, the write cache, I wrote about it here:
http://weblogs.java.net/blog/davidvc/archive/2005/10/the_story_of_th.html
But I wrote this after hearing about this issue from folks in our
performance team. I have never personally had to investigate and
enable/disable the write cache on a system, so I'm flying a bit blind.
Checking with our Solaris guys, but if anybody has the answer for Linux
that would be great. Maybe we can put it on a Wiki page somewhere :)
David
Mike Matrigali wrote:
>
>
> David Van Couvering wrote:
>> 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?
> I am not sure on solaris/linux. On XP it is a path through the hardware
> manager/device manager down the device drop downs - I will see if I have
> it. But probably the easiest is to write a test with one row keyed row
> in a table with an int data column and run an autocommit loop updating
> the single column. If you get ~100 xacts a second (dependent on disk
> speed), then syncing is happening. If you get much higher, like 1000
> then no syncing.
>
> Many of the db's we get compared to, don't even do syncs by default
> leading to the perception issue.
>
> To understand the numbers this will catch also hardware where syncing
> is "correct" but abnormally fast. we have a machine that hardware
> caches synced writes - so syncs are instantaneous unless the cache
> fills, but since it has a battery backup and software
> to flush writes it is not "improper" - but still important to understand
> as not a normal case for many low end systems.
>>
>> 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:
>>
>
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by Mike Matrigali <mi...@sbcglobal.net>.
David Van Couvering wrote:
> 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?
I am not sure on solaris/linux. On XP it is a path through the hardware
manager/device manager down the device drop downs - I will see if I have
it. But probably the easiest is to write a test with one row keyed row
in a table with an int data column and run an autocommit loop updating
the single column. If you get ~100 xacts a second (dependent on disk
speed), then syncing is happening. If you get much higher, like 1000
then no syncing.
Many of the db's we get compared to, don't even do syncs by default
leading to the perception issue.
To understand the numbers this will catch also hardware where syncing
is "correct" but abnormally fast. we have a machine that hardware
caches synced writes - so syncs are instantaneous unless the cache
fills, but since it has a battery backup and software
to flush writes it is not "improper" - but still important to understand
as not a normal case for many low end systems.
>
> 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:
>
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by David Van Couvering <Da...@Sun.COM>.
Great, thanks!
David
Sunitha Kambhampati wrote:
> David Van Couvering wrote:
>
>> Dumb sysadmin question: on Solaris, XP, and Linux, how do you find out
>> if your system is syncing to disk or not?
>>
> For Linux: Use hdparm -W0 on all your drives to turn write cache off.
> http://gentoo-wiki.com/HOWTO_Use_hdparm_to_improve_IDE_device_performance#Write-Caching_-W
>
>
> For Windows (2k) I'd expect something similar for XP.
> go to My Computer -> Right click on Manage --> In computer management
> --> Device Manager --> Pick Disk Drives ---> Right click on the Disk, go
> to Properties --> Pick the disk properties tab and you should see a
> checkbox with writecache enabled.
>
> I dont know about Solaris.
>
> HTH,
> Sunitha.
>
>
>
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by Sunitha Kambhampati <ks...@gmail.com>.
David Van Couvering wrote:
> Dumb sysadmin question: on Solaris, XP, and Linux, how do you find out
> if your system is syncing to disk or not?
>
For Linux: Use hdparm -W0 on all your drives to turn write cache off.
http://gentoo-wiki.com/HOWTO_Use_hdparm_to_improve_IDE_device_performance#Write-Caching_-W
For Windows (2k) I'd expect something similar for XP.
go to My Computer -> Right click on Manage --> In computer management
--> Device Manager --> Pick Disk Drives ---> Right click on the Disk, go
to Properties --> Pick the disk properties tab and you should see a
checkbox with writecache enabled.
I dont know about Solaris.
HTH,
Sunitha.
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by David Van Couvering <Da...@Sun.COM>.
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
>>
>>
>
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by Mike Matrigali <mi...@sbcglobal.net>.
David Van Couvering wrote:
> 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...
hsql is an in memory db which does not do transaction based syncing,
derby is often not going to compare favorably when it does real
transaction based syncing, guaranteed recovery, can handle db's bigger
than memory, ...
>
> 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
definitely would like to see the db create issue separated from the
rebooting an existing db. And in the reboot case we should look at
"clean shutdown" vs. "crash with recovery shutdown". In the reboot
case last time we looked there was a big difference between 1st
load of derby classes and subsequent load, there was a linear penalty
per derby class (and unfortunately # of derby classes is growing
release to release); but it has been quite awhile since anyone looked
at this in detail.
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by Daniel John Debrunner <dj...@apache.org>.
David Van Couvering wrote:
> Well, yes, but one might argue that we're going about it the wrong way:
> "It takes too long to run derby tests because it takes so long to start
> up the database." "Ok, well, let's fix it so that you don't have to
> restart the database for each unit test."
I think for the tests it's really a case of "It takes too long to run
derby tests because we run a separate JVM for each test case".
My total guess is that making derby boot/create databases faster could
bring the tests down from 5+ hours to 4+ hours. My guess for moving to
JUnit wil bring them down to under 2 hours.
It's all good work, complementing each other. Just when I see someone
complain about somthing in open source, my automatic reaction is to get
them involved, complaining won't fix anything, "doing" does.
Seems like the JUnit work should have the option of either re-using &
cleaning the current database, or creating a new one. Might be a useful
comparision across a set of tests.
Dan.
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by David Van Couvering <Da...@Sun.COM>.
Well, yes, but one might argue that we're going about it the wrong way:
"It takes too long to run derby tests because it takes so long to start
up the database." "Ok, well, let's fix it so that you don't have to
restart the database for each unit test."
Not that I'm saying that's a bad idea, I think it's great, and maybe we
can provide some template code for our users who are using Derby for
unit testing. But it doesn't remove the fact that database startup is
slow (except for on Dag's machine :)).
David
Daniel John Debrunner wrote:
> David Van Couvering wrote:
>
>> I personally haven't seen a problem either (except that derbyall takes
>> for bloody ever).
>
> Easy way to fix that, get involved in the effort to switch to JUnit. :-)
>
> http://wiki.apache.org/db-derby/KillDerbyTestHarness
>
> Dan.
>
>
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by Daniel John Debrunner <dj...@apache.org>.
David Van Couvering wrote:
> I personally haven't seen a problem either (except that derbyall takes
> for bloody ever).
Easy way to fix that, get involved in the effort to switch to JUnit. :-)
http://wiki.apache.org/db-derby/KillDerbyTestHarness
Dan.
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by David Van Couvering <Da...@Sun.COM>.
I personally haven't seen a problem either (except that derbyall takes
for bloody ever). However, I do know that a number of our users have
been complaining about this. It could be a perception problem, but
rather than just dismiss this I'd like to do some further investigation.
If it comes down to some tips like "turn on your write cache" and
"increase the checkpoint interval" great, but we should definitely try
to address this one way or the other.
Thanks!
David
Dag H. Wanvik wrote:
> David Van Couvering <Da...@Sun.COM> writes:
>
>> 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...
>
> On my Solaris x86 box, the connect+create new db takes all of three
> seconds.. so where do the tens of seconds come from? Is that in a
> recovery situation?
>
> Dag
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
David Van Couvering <Da...@Sun.COM> writes:
> 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...
On my Solaris x86 box, the connect+create new db takes all of three
seconds.. so where do the tens of seconds come from? Is that in a
recovery situation?
Dag
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by David Van Couvering <Da...@Sun.COM>.
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
>>
>>
>
Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by Mike Matrigali <mi...@sbcglobal.net>.
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
>
>
[jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ 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
--
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
[jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907146#action_12907146 ]
Knut Anders Hatlen commented on DERBY-1664:
-------------------------------------------
I ran the tests on my workstation (running Solaris 11 Express snv_147), and got these results (averaged over 10 runs):
Java 1.6.0_21:
CONFIGURA&|DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
-------------------------------------------------------------------------------------------------------------------
DISK |231 |801 |8 |11 |117
MEMORY |231 |675 |6 |8 |111
CONFIGURA&|DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
-------------------------------------------------------------------------------------------------------------------
DISK |0 |253 |4 |10 |9
MEMORY |0 |153 |2 |5 |4
Java 1.7.0-ea-b108:
CONFIGURA&|DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
-------------------------------------------------------------------------------------------------------------------
DISK |250 |745 |8 |11 |129
MEMORY |250 |660 |6 |8 |138
CONFIGURA&|DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
-------------------------------------------------------------------------------------------------------------------
DISK |0 |247 |4 |8 |8
MEMORY |0 |145 |2 |5 |4
So in my experiments there was no difference in DRIVERLOAD between memory and disk databases, as one would expect.
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: https://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: David Van Couvering
> Attachments: derby_1664.java, perftest.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by David Van Couvering <Da...@Sun.COM>.
I recognize this bug is too vague, but I wanted to get something into
the system so we can start investigating it. If I knew what "fast
enough" was, then perhaps we could have a measure to close it.
If you were to ask me, "fast enough" is no more than 3 seconds with the
default configuration. 5 seconds is pushing it. What do others think?
From a user's perspective it's irrelevant what component is causing the
delay, it just takes too long (e.g. when I run 'connect
jdbc:derby:mydb;create=true').
Also you of course need to describe the hardware configuration. It all
gets so nitpicky, when what we're after is fixing a perception. Maybe
it can be created as a project on the Wiki with a series of JIRAs
attached to it?
David
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1664?page=comments#action_12427303 ]
>
> Daniel John Debrunner commented on DERBY-1664:
> ----------------------------------------------
>
> Might be good to separate this out into:
>
> 1) driver load time
> 2) database create time
> 3) database open time
> 4) create table (first SQL command?) time
>
> Also bugs like this tend to be problematic, when exactly does one close them. Better to identify specific improvements that can be made and address those.
>
>> Derby startup time is too slow
>> ------------------------------
>>
>> Key: DERBY-1664
>> URL: http://issues.apache.org/jira/browse/DERBY-1664
>> Project: Derby
>> Issue Type: Bug
>> Components: Store
>> Reporter: 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
>
[jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=comments#action_12427303 ]
Daniel John Debrunner commented on DERBY-1664:
----------------------------------------------
Might be good to separate this out into:
1) driver load time
2) database create time
3) database open time
4) create table (first SQL command?) time
Also bugs like this tend to be problematic, when exactly does one close them. Better to identify specific improvements that can be made and address those.
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: http://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Bug
> Components: Store
> Reporter: 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
--
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
[jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=comments#action_12427300 ]
Daniel John Debrunner commented on DERBY-1664:
----------------------------------------------
It may be part a store issue, but it's others as well. Some of the startup time is due to the number of classes loaded.
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: http://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Bug
> Components: Store
> Reporter: 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
--
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
[jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by "Gili (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630622#action_12630622 ]
Gili commented on DERBY-1664:
-----------------------------
This is still an issue even in the latest build. Given the fact that Derby is most likely going to be used on client-side applications you should be aiming for something along the lines of 300ms if tables already exist. Anything more leads to a (very) noticeable delay when launching applications.
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: https://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: David Van Couvering
> Attachments: perftest.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1664) Derby startup time is too slow
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=all ]
David Van Couvering updated DERBY-1664:
---------------------------------------
Component/s: Store
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: http://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Bug
> Components: Store
> Reporter: 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
--
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
[jira] Updated: (DERBY-1664) Derby startup time is too slow
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-1664:
---------------------------------
Attachment: derby_1664.java
Attaching a new version of the test, incorporating the following changes:
o Cleaned up the output script. Now there is only one attempt to connect to the results database and create a schema. The generated script should run without any errors.
o Added another argument to the test: the boot instant. This allows the test to calculate how long it takes to fault in the VM.
Here's a revised script for running the test:
rm derby_1664.sql
for counter in 0 1 2 3 4 5 6 7 8 9
do
echo Run number $counter...
export bootInstant=`java 'derby_1664\$CurrentTime'`
java derby_1664 $bootInstant $counter memory 10
export bootInstant=`java 'derby_1664\$CurrentTime'`
java derby_1664 $bootInstant $counter disk 10
done
I ran the test against 3 versions of Derby which support in-memory databases: 10.5.1.1, 10.6.1.0, and the 10.7 trunk. For all three versions on my reasonably peppy machine I saw the following:
1) It took a little less than a second to boot the VM and fault-in the Derby driver.
2) Creating the first database took another second.
3) Creating subsequent on-disk databases took a half second apiece.
4) Creating subsequent in-memory databases took a quarter second apiece.
Here are the results of my test runs:
################################################
10.5.1.1:
CONFIGURA&|VMBOOT |DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
----------------------------------------------------------------------------------------------------------------------------------------
DISK |327 |412 |958 |14 |49 |168
MEMORY |337 |459 |762 |8 |13 |162
CONFIGURA&|VMBOOT |DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
----------------------------------------------------------------------------------------------------------------------------------------
DISK |0 |0 |439 |10 |24 |19
MEMORY |0 |0 |228 |4 |11 |9
################################################
10.6.1.0:
CONFIGURA&|VMBOOT |DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
----------------------------------------------------------------------------------------------------------------------------------------
DISK |323 |436 |1196 |16 |26 |175
MEMORY |333 |482 |915 |9 |14 |170
CONFIGURA&|VMBOOT |DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
----------------------------------------------------------------------------------------------------------------------------------------
DISK |0 |0 |491 |13 |23 |15
MEMORY |0 |0 |253 |5 |12 |7
################################################
10.7 trunk:
CONFIGURA&|VMBOOT |DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
----------------------------------------------------------------------------------------------------------------------------------------
DISK |325 |439 |1149 |18 |28 |176
MEMORY |327 |438 |953 |9 |14 |172
CONFIGURA&|VMBOOT |DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
----------------------------------------------------------------------------------------------------------------------------------------
DISK |0 |0 |499 |13 |23 |15
MEMORY |0 |0 |263 |5 |16 |7
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: https://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: David Van Couvering
> Attachments: derby_1664.java, derby_1664.java, perftest.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1664) Derby startup time is too slow
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=all ]
David Van Couvering updated DERBY-1664:
---------------------------------------
Issue Type: Improvement (was: Bug)
> 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
> 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
--
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
[jira] Updated: (DERBY-1664) Derby startup time is too slow
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=all ]
Rick Hillegas updated DERBY-1664:
---------------------------------
Urgency: Normal (was: Urgent)
Fix Version/s: 10.3.0.0
(was: 10.2.1.0)
Unassigning from 10.2. As far as I know this is not a regression. I think this issue should not block 10.2.
> 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
> Fix For: 10.3.0.0
>
> Attachments: perftest.diff
>
>
> 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
--
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
[jira] Updated: (DERBY-1664) Derby startup time is too slow
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-1664:
---------------------------------
Attachment: derby_1664.java
Attaching derby_1664.java. This program uses System.currentTimeMillis() to measure how long the following operations take:
DRIVERLOAD -- The time to execute Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" )
DBCREATE -- The time to execute DriverManager.getConnection( dbName + ";create=true" );
DBCLOSE -- The time to execute DriverManager.getConnection( dbName + ";shutdown=true" );
REOPEN -- The time to execute DriverManager.getConnection( dbName );
TABLECREATE -- The time to execute Connection.prepareStatement( "create table t( a int )" ).execute()
Each run of the program creates a configurable number of databases, performing the above operations. The first database takes the longest, presumably because it involves faulting in a lot of Derby classes. The program can be run against on-disk and in-memory databases. I ran the program 10 times for on-disk and 10 times for in-memory databases. For each run, I created 10 databases. I then ran the accumulated log script to generate the following results. I ran this test on my macbook pro laptop (10.7 trunk on Java 7 on Mac OSX 10.5.8).
This is the script I used to drive the program:
rm derby_1664.sql
for counter in 0 1 2 3 4 5 6 7 8 9
do
echo Run number $counter...
java derby_1664 $counter memory 10
java derby_1664 $counter disk 10
done
These are the performance numbers for the first database, the one which incurs the brunt of the classloading. The numbers are averaged over the 10 runs of the program. The first column describes the configuration, which is either DISK (on-disk databases) or MEMORY (in-memory databases):
CONFIGURA&|DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
-------------------------------------------------------------------------------------------------------------------
DISK |450 |1123 |36 |33 |174
MEMORY |496 |950 |11 |20 |167
These are the performance numbers averaged over the subsequent databases, again averaged over the 10 runs of the program:
CONFIGURA&|DRIVERLOAD |DBCREATE |DBCLOSE |REOPEN |TABLECREATE
-------------------------------------------------------------------------------------------------------------------
DISK |0 |486 |13 |22 |15
MEMORY |0 |267 |5 |14 |7
I am puzzled that DRIVERLOAD consistently takes longer for in-memory databases than for on-disk databases.
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: https://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: David Van Couvering
> Attachments: derby_1664.java, perftest.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by "martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766531#action_12766531 ]
martin commented on DERBY-1664:
-------------------------------
Startup is slow especially when database was not shut down properly. This seems be user's problem, as it is his responsibility to ensure proper shutdown procedure. Here is a little problem:
while embedded engine starts silently at user's request, user should shutdown engine explicitly.
While first part conforms zero administration claim, the second part is in direct contradiction of the claim.
Typical scenario is: application uses a connection pool - it may connect to a production database or local testing database. For testing database, embedded derby is used. Connection pool can start the embedded driver, but has no method for shutdown. When application starts next times with embedded database, starts are getting slower and slower as database grows.
I think shutdown hooks installed at engine startup should solve the situation. This was proposed long time ago, but never implemented.
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: https://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: David Van Couvering
> Attachments: perftest.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1664) Derby startup time is too slow
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=comments#action_12427298 ]
David Van Couvering commented on DERBY-1664:
--------------------------------------------
And this followup thread from Andrew:
http://www.nabble.com/Re%3A-Startup-time-for-Derby-tf2043724.html#a5626797
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: http://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Bug
> Components: Store
> Reporter: 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
--
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
[jira] Issue Comment Edited: (DERBY-1664) Derby startup time is too
slow
Posted by "martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766531#action_12766531 ]
martin edited comment on DERBY-1664 at 11/11/09 7:37 AM:
---------------------------------------------------------
Startup is slow especially when database was not shut down properly. This seems be user's problem, as it is his responsibility to ensure proper shutdown procedure. Here is a little problem:
while embedded engine starts silently at user's request, user should shutdown engine explicitly.
While first part conforms zero administration claim, the second part is in direct contradiction of the claim.
Typical scenario is: application uses a connection pool - it may connect to a production database or local testing database. For testing database, embedded derby is used. Connection pool like C3P0 can start the embedded driver, but has no method for shutdown. When application starts next times with embedded database, starts are getting slower and slower as database grows.
I think shutdown hooks installed at engine startup should solve the situation. This was proposed long time ago, but never implemented.
was (Author: mstanik):
Startup is slow especially when database was not shut down properly. This seems be user's problem, as it is his responsibility to ensure proper shutdown procedure. Here is a little problem:
while embedded engine starts silently at user's request, user should shutdown engine explicitly.
While first part conforms zero administration claim, the second part is in direct contradiction of the claim.
Typical scenario is: application uses a connection pool - it may connect to a production database or local testing database. For testing database, embedded derby is used. Connection pool can start the embedded driver, but has no method for shutdown. When application starts next times with embedded database, starts are getting slower and slower as database grows.
I think shutdown hooks installed at engine startup should solve the situation. This was proposed long time ago, but never implemented.
> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: https://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: David Van Couvering
> Attachments: perftest.diff
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1664) Derby startup time is too slow
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=all ]
David Van Couvering updated DERBY-1664:
---------------------------------------
Attachment: perftest.diff
I am attaching a set of unit tests I built to time the various parts of startup. On my Solaris x86 with the write cache enabled (my research shows it can't be *disabled* with IDE drives) I have quite acceptable startup times, with the majority of it being spent on database creation.
Next week I'll try some runs on a Linux machine whose SCSI drive has the write cache disabled. I wonder if people who are having trouble are running in such environments...
If these tests look good, I can check them in.
.Testing startup with a NEW database... All measurements are in milliseconds.
Loading driver: 371
Open connection with creating new database: 1212
Creating a table: 232
Time: 1.817
OK (1 test)
.Testing startup with an EXISTING database... All measurements are in milliseconds.
Loading driver: 302
Open connection with existing database: 353
Creating a table: 286
Time: 1.22
OK (1 test)
> 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
>
> Attachments: perftest.diff
>
>
> 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
--
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
[jira] Assigned: (DERBY-1664) Derby startup time is too slow
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1664?page=all ]
Rick Hillegas reassigned DERBY-1664:
------------------------------------
Assignee: (was: 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
> Fix For: 10.2.1.0
>
> Attachments: perftest.diff
>
>
> 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
--
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