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