Hi, Kedar.
As for the Java Web Start system app, last month I investigated and
tested pre-deploying it and noted the results on the wiki
<
http://javaperf.sfbay.sun.com/JSPWiki/Wiki.jsp?page=EEStartupChanges>.
Basically, after installation but before the first start-up I
hand-edited the domain.xml and pre-exploded the directories and
everything worked as expected.
- Tim
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