Kedar,
- ias MBeans have been removed in my codebase
- I'll look into TypeInfos
- AMX has its own logger, but that can be removed
- AdminChannel is now started in its own thread in my codebase, but I
think your timing is incorrect; it takes only 150ms or so for me.
- I've put in some optimizations for dotted names in my codebase
Lloyd
On Oct 23, 2006, at 8:46 AM, 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
>