DynaTrace Ajax Edition

dynaTrace Ajax Edition is a powerful underlying tracking, front-end profiling tool that not only records the browser's request on the network, the rendering time of the front-end page, the DOM method execution time, and JavaScript The parsing and execution time of the code can also track the entire process of JavaScript starting from execution, passing local XMLHttpRequest, sending network requests, and returning requests. DynaTrace Ajax is currently available in two versions, Free edition and Commercial edition

dynaTrace Ajax Installation and use

Figure 1. installation of the operating interface

Click the Center gear icon to configure the properties of the tool, as shown in 2:

Figure 2.Preferences ( property Configuration )

From the:

• " General" Panel: can set the service port, network proxy settings and browser startup path, etc.;
• Agent Panel: You can set the configuration for getting parameters, such as whether to get access to the DOM or method parameters and return values, and so on, all options are selected by default.

You can start DTA to track your pages in two ways:

1. Start directly with the tool, 1, click the drop-down button next to the browser to enter "Manage run Configurations" or simply click "New run Configuration" to add the URL you want to track. Since it can run under a multi-page workflow, you can enter the start URL and navigate to other pages, and DynaTrace will monitor everything in the background.
2. Start DynaTrace from the browser: first open the browser, go to the interface that needs to be traced, then click the button of the browser toolbar, as shown (Enable the tool in the browser plugin before use), Connected/not Connected to indicate the current tracking status

Figure 4. Browser Launch

In addition, in the actual operation process, may need to track the opening page after a series of actions (such as click on a button triggered events, etc.), the free version of the DynaTrace tracking information can not be automatically separated by page or Action, in this case, We can differentiate the time division of each action behavior from the PurePath view by adding a tag (Insert Mark ) during the operation. That is, add a tag before the operation, add a tag when the operation is complete, and analyze the time-consuming request between the added tags from the PurePath view. As shown in 5:

Figure 5. Add tag (PurePath view )

In addition, it also has the function of import and export, the data that will be collected is exported to session file and then imported into DynaTrace for analysis. You can do this by selecting the session you want to export under the Sessions folder in the cockpit panel, or by right-clicking the export Session button from the toolbar. Importing a file is similar to the operation.

Application Case Analysis

performance report ( performance Reports view )

Open the Performance report view from the cockpit panel, as shown in 6:

Figure 6. Performance Reports

The details of all the pages visited are recorded in the performance report view, from which we can get the following information:

• time taken to load the page : OnLoad time[ms] Displays the time it takes to load from the page to the browser to distribute the OnLoad event; Total load Time[ms] shows how long it took to load all the pages
• JavaScript Execution Time : on Client[ms] Total time consumed by all JavaScript functions executed by the JS API or library
• How long the network request took: from Remark, you can see how many requests are in total, and how many of them XHR requests.
• server-side consumption time: On Server[ms] refers to the total amount of time that all requests made by the client begin responding when the server has been over for a long time
• The overall performance analysis report can be obtained from the various panels in the lower right (more detailed information can be seen in the corresponding node in the cockpit panel), for example:
• The network shows how many of the resources are read from the browser cache, how many HTTP forwarding requests consume unnecessary network transmission time, and how much time is saved by merging CSS and JS requests in the same domain.
• The life cycle of the page is shown in TimeLine : The graph reflects the download of network resources in the page process, JavaScript execution, page rendering, CPU usage, and what happened, such as: Load event, XMLHttpRequest and other information.

In my case, the following is what I noticed:

1. The network takes a long time and the number of requests is too large: a total of 896 network requests, of which 300+ request is requested for a picture, 300+ reads the same image from the cache.
2. JavaScript execution time takes 22 seconds: from the Javascript/ajax (a) report in the lower right, you can see that an OnLoad event consumes a total of 13 seconds, and double-click to see its front and back call stack information from the right window.
3. Server-side processing took a total of 20 seconds: This indicates that there may be performance issues on the server side, and it is recommended that you use the Performance Inspector tool to analyze server-side performance issues, which are no longer detailed.
4. The Remark Bar also shows a total of 23 XMLHttpRequest requests made by the page: This can be used to find the point in time from the event line in the timeline. The next section will discuss these issues in more detail.

Timeline ( timeline view) - page life cycle

The timeline view can be opened by double-clicking the TimeLine node in the cockpit panel or by right-clicking on a URL in performance report and selecting "drilldown-timeline " Open it. Depending on the performance report view , the TimeLineof long-running URLs can be opened by using toolbars or the right-click menu to open more options, such as the color values of content types and JavaScript triggers, or to show more events such as mouse movement, Click and keyboard events. Open the timeline view of this case, as shown in 7:

Figure 7. Timeline

In this view, we can observe:

1. CPU usage shows the time that JavaScript execution causes the browser to consume CPU
2. Time spent in JavaScript execution: the segment from which the right blue block is viewed takes longer, and the mouse hovers over it to see that the Load event on is triggered and takes nearly a second
3. Browser Rendering, hover can be found mostly due to the time required to calculate the layout, generally on IE above the relative will be more obvious
4. Network requests parallel download time, on the one hand from the number of requests too much, one of the more obvious is that there is a xmlhttprequest spent nearly 7 seconds of processing the Server
5. The event axis shows the mouse click event, the XMLHttpRequest event, and the OnLoad event

Enlarge the portion of the right network request for a long time (in my case, from 16s to 29s time slices ), by clicking the left mouse button at the beginning and dragging to the end position to release the mouse drag, the view will zoom to the time slice shown below, such as 8 As shown:

Figure 8. Zoom in on the timeline

By right-clicking on the magnified time slice, select "Drill down totimeframe e" into the PurePath view, showing all the activities on the currently magnified time slice.

PurePath ( path View )-JavaScript , DOM and the Ajax detailed description of the issue

You can either double-click the PurePath node in the cockpit panel or select the right-click on the timeline to select "Drill down totimeframe " into the PurePath view, Go further into each action to see which events trigger the execution of JavaScript and which functions take longer to execute.

This goes on to the PurePath view as described in the previous section, as shown in:

Figure 9.PurePath View

Mouse click on the second time slice that JS occupies 14 seconds, the panel will also update the currently selected live information, display the JavaScript code execution process, including the execution time of each method and the parameters of the call and the return value. Not only can we see JavaScript methods, we can also see DOM access and AJAX requests.

From the detail bar we can observe

• Start: The starting time of an activity
• Duration[ms] : Duration of the activity, including the time of the subtree activity
• Js[ms] : Total time-consuming JavaScript execution, including asynchronous subtree execution times without waiting time
• Total[ms] : The duration of the activity itself from start to finish, not including the execution time of the child activity
• Exec[ms] : The time that the activity itself executes, excluding the time required for its child activity
• Size : The total number of nodes in the tree, including the number of nodes for all child activities.

Mouse click on any of the above column can be sorted, according to the length of time JS execution through the mouse click Expand can also be right-click on the "expansion subtree" to expand the hierarchy to find out which method of the call resulted in the execution of such a long time. From the call stack, it can be seen that Contentdomhandle calls from the application's JavaScript API take the longest, and from its subtree you can observe the time distribution of JavaScript execution:

• The Addcontextmenu<div> method executes a lot more times, although the execution time of the method itself is 150ms, but the number of calls will result in the overall execution time being longer.
• Simulateslideclick Time 2.5 seconds
• Concord.util.events.publish Time 3 seconds

To make it easier to discover the performance problems of these functions, you can right-click the contentdomhandle method and select "Drill down->hot spots " to enter HotSpots View .

In addition, the PurePath view provides a variety of analysis methods that allow you to filter or find the data items you need by typing directly into what you are looking for, or by adding filtering rules through the right-click menu or toolbar buttons to let the software display only specific information.

Hotspot ( hotspot View )- where performance has been reduced

In summary, you can enter this view from Purepath-->drill, or you can open the HotSpot view directly from the panel to analyze all JavaScript, DOM, and page rendering operations accessed in the Browse.

Then the previous section of the Contentdomhandle () method call is an example, as shown in:

Figure 10.Hotspot Case View

You can see the number of calls per method, the execution time of JS, and the total execution time, among others:

• The back traces bar shows who called this function, called several times, from the <return-closure> call of the method by Dojo 2 times, and the method itself calls the execution time is very short only 3ms (Exec[ms])
• The Forward traces bar shows which functions are called by this method, invocations indicates that the method has been called several times, the activity takes 12.7s (Total[ms]), and Exec[ms] indicates the time required for the method to execute. JS[MS] The execution time of the total JavaScript.
• The bottom of the interface shows the source code of the JavaScript selected in the back traces tree or Forward traces tree

From my example, it is obvious that the following performance issues are found:

1. Addcontexmenu (<div>) was called 30 times, and JavaScript execution consumed nearly 7 seconds. The effect of this method is to add a right-click menu for each Slide, which means that the file contains 30 pages and is called 30 times, which not only increases the browser's execution time, but also consumes more memory.
2. For the other two more time-consuming methods, the Simulateslideclick and Events.publish methods call for almost 3 seconds and 2.5 seconds, and the number of calls is not many, which requires the extension of Trace to see if there is a performance problem or there is a place to improve;

Here we can basically find out that the time-consuming 13-second JavaScript from the timeline view is a matter of which function calls are taken up, and some of the more obvious performance issues are found. Go back to the General Hotspot page to see if there are any other performance issues (double-click the hotspot node from the cockpit panel) as shown in:

Figure 11.HotSpot View

The default is to sort by the time-consuming (Exec[ms]) of the operation or method itself, and we find that in addition to the time-consuming rendering of the browser, the most likely performance problem is the invocation of the application method. In my case, for example, the following questions were found:

1. LoadState Total (including sub-methods) executed for 3.7 seconds, the method itself consumes nearly 2 seconds of time, this method is only called once, whether there is room for improvement in the need to look through the source or directly with the developers to communicate;
2. Dojo.destroy (<div>) was called 122 times and took a total of 1.3 seconds;

Double-click Dojo.destroy (DIV) to open its back traces, as shown in:

Figure 12.dojo.destroy

It is known that Dojo.destroy (<div>) was only called by the Applyslidesorterstyles method for 1 seconds at a time, which is a questionable performance issue. Alternatively, you can sort by the total execution time, as shown here, where you can find the most time-consuming method of entry:

Figure Sort by total consumption time

Network (Network view) - Analysis " Dialogue "

Finally, let's look at another view of DynaTrace-Network view, by double-clicking the network node in the left cockpit panel, or by right-selecting Drill down–network from a URL in Summary view to enter Network view, which shows all networking requests, as shown in:

Figure 14.NetWork View

The Network view highlights the ultra-slow requests and connection wait times.

Each request is marked with color in this view, and the most time-consuming download request is highlighted in red. By default, they are arranged in the order in which they occur on TimeLine, and you can click on any column to sort. For each request we can see whether the resource is from the browser cache (Cached bar), request type (Network or Ajax), HTTP status, Mime type, size, time spent on DNS, network connection, server response, network transport, and wait. The bottom of the interface shows the HTTP request and response headers and the actual content returned.

Common performance issues and workarounds:

• The number of JS or CSS is too many: you need to properly merge JS or CSS in the same domain to reduce the number of client requests
• JS size is too large to cause the download time in the local area network is too long: the size of larger files can be compressed on the server side, for example, using Dojo Shrinksafe or YUI for compression
• Too many pictures: You can use CSS Sprites to combine some small pictures together to become a picture, which can reduce the load on the server and improve the loading speed of the Web page.

Automated Data collection

Usually we are all on the performance of the page with a manual way to access each page and then use DynaTrace record and collect data, but if you want to record each page or for each different version of the application to do these actions for only a few pages to do these operations also need to pay a greater effort. Fortunately, DynaTrace also provided some of our new Feature. You can automatically collect data by using scripting tools instead of manually driving your browser. When you run a test script with a tool such as Selenium, Watir, Webaii, DynaTrace can automatically collect performance information from each browser session.

There are two ways to automate the collection of data using Selenium integration DynaTrace;

• Use some of the advanced Features provided by DynaTrace, such as DynaTrace Selenium Runner (for commercial users only) ( Com.dynatrace.webautomation.DynaTraceSeleniumRunner). or Dynatraceseleniumhelper ( Com.dynatrace.webautomation.DynaTraceSeleniumHelper) or use Dynatraceselenium instead of defaultselenium, such as the following code:

public class Gospacedynatraceseleniumtest {

Selenium Selenium = null;

@Before

public void startup () {

Selenium = new Dynatraceselenium ("localhost", 4444, "*iexplore",

"http://localhost:9090");

Selenium.start ();

}

• If you are using the free version, you can automate it by configuring environment variables. is set to automatically connect the dynaTrace when the browser starts, so that when the Selenium script starts executing the browser, it automatically connects to DynaTrace, allowing DynaTrace to collect the data automatically. For the auto-add Mark, insert the following code in the Selenium script:

void Addmark (String marker) {

Defaultselenium.runscript ("Try

UNKNOWN macro: {_dt_addmark (' "+ marker +" ')}

catch (e) {} ");

}

DynaTrace Ajax Edition