Bug 101658 - Persistence initializer accounts for 40% of startup time.
Summary: Persistence initializer accounts for 40% of startup time.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: persistence
Version: nightly
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Vadim Nasardinov
QA Contact: Jon Orris
URL:
Whiteboard:
: 102336 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-05 11:19 UTC by Daniel Berrangé
Modified: 2007-04-18 16:56 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-02 17:41:51 UTC
Embargoed:


Attachments (Terms of Use)
shaves off 5 seconds at the expense of no longer supporting UDCTs (4.16 KB, patch)
2003-10-30 23:41 UTC, Vadim Nasardinov
no flags Details | Diff

Description Daniel Berrangé 2003-08-05 11:19:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314

Description of problem:
The the persistence initializer in Troika is considerably slower than that in
5.2 & earlier. In 5.2 is takes 4 seconds to load core & CMS:

2003-08-05 12:05:17,191 [ main] INFO  initializer.Script - Running initializer
com.arsdigita.persistence.Initializer (4 of 51 complete)
2003-08-05 12:05:22,174 [ main] INFO  initializer.Script - Running initializer
com.arsdigita.globalization.Initializer (5 of 51 complete)

Where as in 5.3 is takes 15 seconds:

2003-08-05 12:06:14,694 [ main] INFO  initializer.Script - Running 
initializer com.arsdigita.persistence.Initializer (4 of 36 complete)
2003-08-05 12:06:29,432 [ main] INFO  initializer.Script - Running initializer
com.arsdigita.globalization.Initializer (5 of 36 complete)

The complete initializer sequence takes 36 seconds, so persistence accounts for
about 40% of the startup overhead. 

This isn't a hughly critical problem, but if there are any simple things that
can be done to speed this up would be benefical to developers who frequently
restart servers. For example, in 5.2 we disabled generation of DOT graphs except
when corresponding log4j logger used them.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start the server
2. Watch the timestamps on the initializers

    

Actual Results:  Takes 15 seconds to load with core & cms apps.

Additional info:

Comment 1 Vadim Nasardinov 2003-08-05 14:47:52 UTC
There is substantial overhead added to the persistence initializer by 
the versioning observer.  With the versioning.PrePersistencInitializer 
enabled, the total startup time is 30 seconds on my 
machine. Persistence accounts for 11 seconds. 
 
If versioning.PrePersistenceInitializer is disabled, the persistence 
initializer takes 5 seconds. 
 
In theory, it is probably possile to reduce this overhead to well 
under one second, i.e. less than 10% of the persistence startup time, 
bringing the total persistence startup time down to within the old 
5-second range. 
 

Comment 2 Vadim Nasardinov 2003-10-29 21:25:49 UTC
*** Bug 102336 has been marked as a duplicate of this bug. ***

Comment 3 Vadim Nasardinov 2003-10-30 23:41:13 UTC
Created attachment 95617 [details]
shaves off 5 seconds at the expense of no longer supporting UDCTs

This patch against //core-platform/dev/...@37530 shaves about 5 seconds off the

PDL parse time on my machine.

The way versioning currently works, you can add a new object type at any time,
and the versioning dependence graph will be properly updated.

With this patch, the PDL parser gives versioning a complete list of all
object types, and after that no further updates are possible.  The upside
is that this reduces the required computation time fairly significantly.

The downside is that if you add a new object type to the syste at runtime
(as in the UDCT scenario), the versioning dependence graph won't be updated.
So, UDCTs won't work.

On balance, the current way of doing things only works in a single JVM
environment.  If you add a UDCT, the JVM to which the request is dispatched
will update its dependence graph properly.  All other servers will be unaware
of it.

So, it's not clear to me if we would actually lose anything by applying
this patch.

Comment 4 Daniel Berrangé 2003-10-31 00:14:57 UTC
UDCTs are already broken in a multi-JVM environment so we don't loose anything
with this patch. see bug 102891. I imagine the fix for this bug would facilitate
a hook for updating the versioning graph too.


Comment 5 Vadim Nasardinov 2003-10-31 15:49:14 UTC
I applied the patch in change 37550.

It would be possible to support runtime object model modifications
modulo bug 102891.  ObjectTypeMetadata could be made to operate in two
different modes.  The first mode would be for server startup: traverse
the AST in its entirety first and propagate versioning dependencies
second.  (This is the current implementation with the above patch
applied.)  After the server startup, we could switch into the second
mode, in which the dependency graph is refreshed whenever a new object
type is added.

One reason I chose not to put the two-mode logic in is because there
are no currently no tests for it, and writing one would take more time
than I currently have.  Another reason for not bothering to implement
the two-mode logic is bug 102891.  Until it is resolved, runtime
object type model modification is broken any way.


Comment 6 David Lawrence 2006-07-18 03:50:22 UTC
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.

Comment 7 Daniel Berrangé 2006-09-02 17:41:51 UTC
Closing old tickets



Note You need to log in before you can comment on or make changes to this bug.