Thanks for bringing this up. I will work on it and let you know.
Prashanth
Suveen Nadipalli wrote:
> Hi Prashanth/Team,
>
> Can we have a quick 1/2 hour to an hour meeting every 2 weeks, to go
> over the status. Also we can discuss more on the next steps, various
> configs and profiles etc.
> We can update the dashboard with the latest status after the meeting.
> If there is any other admin team meeting which you guys discuss all
> these, then I can also attend that meeting.
>
> Let me know in case if you guys are ready with the patch, I can verify
> the patch in terms of the performance improvement and also generate a
> new profile.
>
> Thanks
> -Suveen.
>
> Prashanth Abbagani wrote:
>
>> 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
>>>
>>
>