I have created a page at
http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=StartupPerformanceAnalysis
to track the progress of these items. Also the Profiler data is now
available at
http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=GlassfishStartupProfiling
. Those who are looking into this, we can get together and take help
from Suveen to generate the profiling numbers, to see how much your fix
can improve the startup performance.
thanks
Prashanth
Kedar Mhaswade wrote:
> Here are some more things to observe and modify for performance
> improvements for 9.1. We studied profiles generated by both
> NetBeans profiler and JProfiler. The study was done on a simple
> configuration of one cluster comprising of two instances. The DAS
> and server instance processes were studied.
>
> It may be the case that there are some false measurements/observations,
> in which case you can just update the alias. If there are some real
> benefits, please consider doing changes for 9.1 release.
>
> If you want to see the actual profiles, let Prashanth know.
> Prashanth, can you also send a pointer (external) to the profile
> images that you generated?
>
> ----------------------------------------------------------------
> Performance runs done by Prashanth and Suveen.
>
> Here are the observations and action items:
>
> - LocateRegistry.createRegistry spends a lot of time in bind call.
> It may well be essential overhead. (Nandini to investigate).
>
> - When AMX MBeans are being created, in LoaderRegThread,
> TypeInfos.instance() method is being called several times. This
> results in several loadClass() calls. (Lloyd to investigate).
> In non-DAS server, only logging AMX MBeans are available. There too,
> this call (TypeInfos.instance()) takes significant amount of time,
> mainly because the loadClass() seems to be called several times.
> Also, why does AMX initialization result in addLogger() calls?
>
> - AdminChannelServer constructor takes almost a second to return.
> This does not include the time to write the stub to the file system.
> (It appears that SecureRandom takes time -- Nandini to investigate).
>
> - registerValidator() call in adminService initialization/startup needs
> investigation. (Kedar to investigate).
>
> - There are 5 invocations for ConfigContext.refresh(). Are these needed?
> 1 call - JMSProvider (This could be optimized).
> 2 calls - JMSRA(setMDBContainerProperties()), J2EEServer -- there
> are multiple calls
> to AppserverClusterView class. Siva needs to investigate. This class
> should be used only when you want to get the information *without token
> replacement* from the config context. At all other times, the
> ApplicationServer.
> getConfigContext() should be used.
> 1 call - CreateConfigContext -- this is essential.
> 1 call - AdminService.contextImpl.setConfigContext()
> Bottom line -- use the config context from Application server all
> the time,
> except when you need to do things differently. AppserverCusterView
> class is
> to be used sparingly.
>
> - Reinitialization of loggers take significant amount of time.
> (someone needs to invastigate).
>
> - On non-DAS instances, the ejb-timer application is enabled by default,
> but timers are not available, because timer datasource is not
> configured.
> This results in the timer beans being loaded at the startup. Mahesh
> suggested that it should continue this way. Maybe it needs some
> investigation.
> The three system applications *on non-DAS instances* take around 11%
> of the startup time.
> ejb-timer -- Mahesh to investigate.
> mejb-app -- Kedar to investigate (is MEjb needed here)?
> __jwsappclients -- Tim to investigate (can this be optimized).
>
> - MonitoringRegistrationHelper takes some time to initialize even when
> monitoring is turned off. Can this be improved? (Siraj/Kedar to
> investigate).
>
> - getServiceByName in EE takes some time. Needs investigation.
>
> - What does initializeDottedNames *for config MBeans* do in non-DAs
> server
> instances? -- there are no config MBeans in this instance. Kedar to
> investigate.
>
> - There are a few ias-domain MBeans in DAS. What do they do? Nandini to
> investigate.
> -----------------------------------------------------------------------------
>
>
> Thanks,
> Kedar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>