PDFs


This page applies to an earlier version of the AppDynamics App IQ Platform.
See the latest version of the documentation.


On this page:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
52 rates
Web applications built using Single Page Application (SPA) principles minimize network traffic by transferring to the browser itself much of the computing work for creating what the user sees. The initial page request downloads everything that is necessary for constructing all aspects of the application, with the possible exception of some data, including html partials and fragments, that may be fetched dynamically from the back-end in response to user interaction.

Browser RUM supports virtual pages created using the AngularJS framework, sometimes known simply as Angular. The individual Views (a meaningful non-transient UI presentation) that the user sees are referred to as virtual pages. In AngularJS, a virtual page is comprised of the rendered template of the current route in the context of the main layout file.

Instrumentation Support for AngularJS

The JavaScript Agent supports instrumentation by default for AngularJS versions 1.x. For Angular versions 2 and 4, you would need to manually report events with the JavaScript API

Routing Engines

AngularJS applications that have multiple Views use a route to move from one virtual page to another.  You can use AppDynamics Browser RUM to instrument any virtual page that uses either of two routing engines, ngRoute or ui-router.

Metrics

Because virtual pages are constructed in the browser, normal page view metrics must be adjusted.  In essence, what a metric for AngularJS must do is correlate the time between various routing events, using their timestamps. Metrics are calculated as follows:

Full Metric NameShort Metric NameHow Calculated
End User Response Time
(not used for waterfall UI) 
PLTvirtualPageStart to virtualPageEnd
HTML Download TimeDDTviewChangeStart to viewChangeEnd
HTML Download and DOM Building TimeDRTviewChangeStart to viewDOMLoaded
DOM Building TimeDPTviewChangeEnd to viewDOMLoaded
DOM Ready Time
(used instead of PLT for waterfall UI) 
DOMviewChangeStart to viewDOMLoaded

Because the two routing engines function in slightly different ways, what the AppDynamics event consists of differs slightly, based on the engine.  

AppDynamic Event NamengRoute Equivalentui-router Equivalent
virtualPageStartlocationChangeStartstateChangeStart
viewChangeStartrouteChangeStartstateChangeStart
viewChangeEndrouteChangeSuccessstateChangeSuccess
viewDOMLoadedviewContentLoaded viewContentLoaded 
(may happen multiple times -  timestamp overwritten each time)
viewFragmentsLoadedload time of the last HTML fragment
xhrRequestsCompletedresponse time of the last XHR requests
viewResourcesLoadedload time of the last resources
virtualPageEndthe latest one among viewContentLoadedxhrRequestsCompleted and viewResourcesLoaded

Page Load Process Visualized

Visualized the page load process looks something like this:

Compare these to the standard page metrics, which are shown here.

Excluding Heartbeats or Background Requests from Timings

You may wish to exclude certain events from your virtual page timings.  To do this you can customize the JavaScript agent when you inject it.  

Add the following snippet before you add the JavaScript agent file, adrum.js, to the page:

Option for excluding XHRs
<script type="text/javascript">
(function(config) { 
   (function(spa) {
        (function(angular) {
            (function(vp) {
                vp.xhr = {
                    "exclude": {
                        "urls": {
                            pattern: '.*/dealActiveUsers'
                        }
                    }
                };
            })(angular.vp || (angular.vp = {}));
        })(spa.angular || (spa.angular = {}));
    })(config.spa || (config.spa = {}));
})(window["adrum-config"] || (window["adrum-config"] = {}));
</script>

Seeing Correlated Server Times

Since there isn't a regular HTML page timing to which correlated server timings can be linked, to see server times you must drill down from the Dashboard or Snapshot virtual page view to the component XHR requests. The server times can be seen there.

  • No labels