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): 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:
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.
*** 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 of it. So, it's not clear to me if we would actually lose anything by applying this patch.
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