Red Hat Bugzilla – Bug 101658
Persistence initializer accounts for 40% of startup time.
Last modified: 2007-04-18 12:56:38 EDT
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):
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.
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
*** Bug 102336 has been marked as a duplicate of this bug. ***
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
So, it's not clear to me if we would actually lose anything by applying
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.
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.
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.
Closing old tickets