How does Deep Inheritance work and what is its Impact?

Document ID : KB000017623
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

Deep Inheritance Functionality

For normal instrumentation, the agent only sees one inheritance level on the bytecode level. Let us use the following inheritance structure as an example:

Class A
|- Class B
|-Class C
|- Class E

Let us assume, that you have a PBD directive which instructs the ProbeBuilder to monitor everything inheriting from "Class A".

On startup, the application sends "Class E" through the Classloader and the ProbeBuilder. At this stage, since the ProbeBuilder has no idea that "Class E" inherits from "Class A", it would not instrument it.

However, with deep inheritance enabled, when all the other classes are going through the Classloader some time after the startup, it always checks the complete structure and tries to instrument it using Dynamic Instrumentation. Without Deep Inheritance enabled, this would not happen. This is because it would not check the full inheritance once a new class comes up. So, in the above example, "Class E" would not be instrumented.

Deep Inheritance Impact

Although the Deep Inheritance feature has played a crucial part in providing a complete monitoring solution, the mechanism of checking the full inheritance tree and performing Dynamic Instrumentation often comes with a cost.

Due to its described nature, Deep Inheritance causes some overhead, in which on most engines, usually happens at startup. It is especially significant in frameworks using dynamic proxy classes. For example, frameworks like Spring which are created on the fly, are generally dangerous for Deep Inheritance. In scenarios like this, the AutoProbe.log can often be used to identify these classes, and a skip of these classes in the PBD could help addressed the overhead issue.

On the other hand, removing/disabling the Deep Inheritance feature will mean, on most frameworks, having less metrics and more gaps in transaction traces.

Solution:

In APM release 9.5.5, the Deep Inheritance feature has been revised to clamp the number of classes being monitored to avoid overhead on response time and memory consumption.

It will also be disabled by default on releases after 9.5.5.

For earlier APM releases, to address the overhead it incurs, the recommendation is to only enable it in a test environment to identify classes of interest. So, a custom PBD for deep tracing can then be created on only those classes identified. Additionally, it can have Deep Inheritance disabled in the Production environment.