ApplicationInsights-JS

Performance Monitoring (since v2.5.7)

The SDK now provides support for local client side performance monitoring and testing, this support does not send any telemetry or events to Azure Monitor as it has been designed to help developers validate and measure the performance of the SDK and any optional user instrumented code.

It can be enabled via configuration (enablePerfMgr) during initialization or by setting the performance manager directly on the Application Insights instance (setPerfMgr()).

The SDK comes with a default implementation of the performance manager which will fire the new perfEvent on the INotificationManager, so you can receive a notification of these events by adding a INotificationListener which contains a perfEvent implementation.

The easiest way to view and monitor these events in your running application/website would be to use the new DebugPlugin extension, which now listens and displays to the INotificationManager events.

The default INotificationManager implementation will (by default) only fire a perfEvent for top level events, which are defined as events that have not occurred within the same execution cycle of a previous (incomplete) perf event. This behaviour can be changed to fire a perfEvent for every instrumented section of code via the perfEvtsSendAll configuration setting. Where the tracking of the current execution cycle of a performance event is automatically handled by the provided doPerf() helper.

Example of the IPerfEvents captured by the default IPerfManager using the DebugPlugin extension to visualize the captured events. DebugPlugin Example

The interfaces

The SDK avoids (as much as possible) from directly using hard coded implementations and only uses the following interfaces as part of instrumenting the code for performance monitoring. This allows you to provide your own implementation to support your requirements at runtime and testing.

The only directly named class references are in the ApplicationInsight Core instances where they will create a PerfManager instances when the enablePerfMgr configuration is enabled. If you want to use your own performance implementation then do not enable the enablePerfMgr configuration setting, and just call the setPerfMgr() with your IPerfManager after the ApplicationInsights has been created.

IPerfManager

Provides the basic interface for creating, monitoring and firing performance events

This interface is used by the system to start “create()” and complete “fire()” performance events, the default provided performance manager PerfManager provides a simple implementation that will create a new IPerfEvent instance for every call to it’s create() function and will complete and fire a INotificationManager.perfEvent in response to calling it’s fire() function.

The basic usage is that you call “create()” at the beginning of the segment of code that you want to measure and when the code is complete just call the “fire()” method with the IPerfEvent object returned from the create(). By following this pattern the implementation of the IPerfManager can control the exact implementation of IPerfEvent instance that is used for tracking the performance.

Methods of the IPerfManager

IPerfEvent

The basic interface used to generate performance event metrics for instrumented code

This is a generic interface for holding the details about the instrumented chunk of code, the SDK does not directly create instances of this interface but rather uses the instances returned via the IPerfManager.create().

The fields of the IPerfEvent

Methods of the IPerfEvent

Provided Implementation helper

doPerf()

Helper method that is used by the SDK to wrap the code to be measured

This is the primary helper used by the SDK to instrument a block of code that we have identified as a critical block that should be monitored / tested. We have exported this helper to allow you to instrument your own code as part of the normal execution cycle.

It is designed as a wrapper implementation where the 3rd argument func is the code that is being monitored. The implementation handles cases where a performance manager is not enabled or available, so it is safe for you to include this into production code.

Signature

The helper uses callback functions for constructing the source (name of the event) and details (payload of the event) to avoid any expensive string or object construction when performance monitoring is not enabled.

doPerf(mgrSource: IPerfManagerProvider | IPerfManager, getSource: () => string, func: (perfEvt?: IPerfEvent) => T, details?: () => any, isAsync?: boolean) => T

Example usage


public myFunction(someArgument: any) {
    return doPerf(appInsights, () => rootName + ":myFunction", () => {
        // This is the code that will be instrumented

        // As a wrapper the doPerf supports returning the value returned by the func argument
        return true;
    }, () => ({ details: someArgument, retry: 1 }));
}