Call graph vs. profile

[Kenny_Yu]

Besides AppD, we use java profilers, or simply thread dumps, in non-production environments. My understanding is that AppD's call graph collects timing stats along the execution path of a thread, while profilers sample threads on intervals and collect/deduce timing stats aross threads.

AppD's call graph, or a transaction nsnapshot, has granularity limitations - "Some packages have been excluded from this Call Graph". I assuem that the call graph is gathered through bytecode instrumentation and to limit the cost, you have to exclude low-level libraries. 

A profile, or a cpu snapshot,  doesn't have that limitation as it is based on full stack traces. It could, for example, show that obj.equals() is taking the time.

Is there a way in AppD to get a CPU snapshot, that is an aggregate of all threads, but includes all active methods?

Thanks

Kenny

[Arun_Dasetty]

Hi Kenny,

We would like to clarify that we exclude packages but not customer packages rather we will exclude third party packages like com.mysql.* , org.springframework.* . java.util.* etc which usually cusotmer not interested, However if customer wants to see we have option to force include packages to show in UI which you do this changes from Configure -> Instrumentation -> Call graph settings in controller UI.

Regarding the limits imposed by appdynamics, we see AD is designed to give more details on real world distributed applications with very less performace overhead as agent is desinged and comes with certain default limits like 5000 call elements per call graph(which in general a BT will not have such long code paths) and other such limits to make sure AD agent works with very less consumption of memory in java/iis server, However customer can force to increase the limits using node level propertied if required Or he can set monitoring level to "Development" mode where no agent limits are applied, Hope that information helps.

Regarding other query, Yes AD agent collects snaphots for BT monitored discoverd, if discovered BTs missing target API, user can always define custom pojo rule with all default packages included and that will give more visibility in snapshots and call graphs, Hope that information helps.

refer doc https://docs.appdynamics.com/display/PRO39/Monitoring+Levels

Regards,

Arun

[Arun_Dasetty]

Hi Kenny,

We would like to clarify that we exclude packages but not customer packages rather we will exclude third party packages like com.mysql.* , org.springframework.* . java.util.* etc which usually cusotmer not interested, However if customer wants to see we have option to force include packages to show in UI which you do this changes from Configure -> Instrumentation -> Call graph settings in controller UI.

Regarding the limits imposed by appdynamics, we see AD is designed to give more details on real world distributed applications with very less performace overhead as agent is desinged and comes with certain default limits like 5000 call elements per call graph(which in general a BT will not have such long code paths) and other such limits to make sure AD agent works with very less consumption of memory in java/iis server, However customer can force to increase the limits using node level propertied if required Or he can set monitoring level to "Development" mode where no agent limits are applied, Hope that information helps.

Regarding other query, Yes AD agent collects snaphots for BT monitored discoverd, if discovered BTs missing target API, user can always define custom pojo rule with all default packages included and that will give more visibility in snapshots and call graphs, Hope that information helps.

refer doc https://docs.appdynamics.com/display/PRO39/Monitoring+Levels

Regards,

Arun