The Ajax View approach is to insert a server-side proxy (or web server plugin) in-between the web server machines and the end-user’s browser. This proxy captures the web application’s JavaScript code as it is being sent to a browser and rewrites the code to insert extra instrumentation code. The injected instrumentation code runs with the rest of the web application inside the end-user’s browser and can capture performance, call graph, application state and user interaction information, providing visibility directly into the last hop of the user’s experience.

Because Ajax View is rewriting web application code dynamically each time a user visits the web site, it can:

• Serve different instrumentation code to different users. This allows us to distribute instrumentation code across many users, spreading the cost of gathering lots of information such that no single user pays a high performance penalty.
• Adapt an instrumentation policy and serve different instrumentation code over time. For example, we can drill-down into performance problems and gather extra context about bugs.

Remotely Monitoring Client-Side Web App Performance and Behavior

By Emre Kıcıman and Benjamin LivshitsDo you know what your users are experiencing when they visit your AJAX application?  Is your JavaScript code running fast, slow, or generating errors in your users’ browsers?

The Ajax View project at Microsoft Research aims to give developers easy visibility into their web apps’ performance and behavior as the apps run in end-users’ browsers.   Ajax View uses a server-side proxy to rewrite JavaScript “on-the-fly” and automatically inject instrumentation code into a web application.  This instrumentation provides end-to-end visibility into app performance, behavior and critical state.  “On-the-fly” rewriting allows Ajax View to serve different instrumentation across users and over time, capturing more detail about app behavior while minimizing per-user performance overhead.

In this lab, you will use an early prototype of Ajax View technology to quickly enable cross-browser performance profiling of web apps, without modifying the original web app code or the client-side browser.   First, you will startup Ajax View as a client-side proxy.  Then, you will browse a web application while Ajax View monitors its function-level performance, and see the resulting profile information.

Research Prototype Warning:  Ajax View is an early preview of work we have been doing at Microsoft Research.  Our prototype is often rough around the edges, not as fast as it could be, not scalable, etc.

Performance Profiling Walk-Through

First, if you haven’t already, download and install the Ajax View prototype.

Then, let’s start the Ajax View client-side proxy:

• Start Ajax View by clicking on the Ajax View Proxy icon in your start menu.

If you are running Windows Vista, you should see a dialog asking you to allow Ajax View to run with administrator privileges. Click allow.

• Ajax View is now running as a proxy, ready to intercept and rewrite web applications’ JavaScript code.  By default, Ajax View listens for connections on port 8888.
• Next, let’s open a web browser and use a web application:

Open either Internet Explorer or Firefox.

Because Ajax View does not require browser plugins or ActiveX controls, it can profile and monitor app behavior as they run in either Internet Explorer or Firefox.

Note: Both browsers’ proxy settings have already been preset to use the Ajax View proxy

• Set the browser’s proxy settings to localhost port 8888:
• Open the Tools menu, and click on the Internet Options menu item.
• Click on the Connections tab in the Internet Options dialog box.
• Click on the LAN Settings button in the Connections pane.
• Uncheck “Automatically detect settings.”
• Check “Use proxy server for your LAN” and ensure that the address is set to localhost and the port is set to 8888.

Note: The Ajax View proxy does not support HTTPS / SSL connections.  If you want to browse HTTPS sites while Ajax View is enabled, click through to the Advanced settings, uncheck the option to “use the same proxy server for all protocols,” and enter Ajax View only for the HTTP protocol.  Leave the Secure, FTP  and SOCKS protocol proxies blank or set to your previous proxy.

• Go to http://maps.live.com/
• Once the page has loaded, search for hotels in las vegas by typing “hotels” in the top search box, and “las vegas, nv” in the address box.
• Double-click a few times in the middle of the map to zoom into the center of Las Vegas.  While you use maps.live.com, Ajax View is monitoring and capturing the applications behavior.
• Now, it’s time to look at the information that Ajax View has gathered.

Press CTRL+T to open a new tab.

• Open the web page http://fakeurl.com/?&AJAXVIEWREQUEST=GET=main.html

This URL will be intercepted by the Ajax View proxy.  Instead of sending this request to “fakeurl.com”, Ajax View will return its own statistics page.

• Click the “JS Performance Statistics” link.
• The right pane is now showing a list of urls that we have visited while running our application, grouped by top-level domain. The first column shows the URL itself, the second column shows the number of JavaScript functions and scripts that are defined within the file, and the third column displays the performance of the slowest function within the file.
• Let’s click on one of these URLs, the “mapcontrol” file, shown as the link:sc1.local.live.com/mapcontrol.asjx?…
• Now, the right pane is showing a list of all the JavaScript functions defined in this file.  The columns of data show performance information for each function.
• Let’s see what the slowest functions were. Click on the “Mean Time (ms)” column to sort the table by this column.
• Let’s get more detail about the performance profile of double-clicking to zoom in on the map.   Click on the “Details” link next to the “this.Init” function.
• Now, we see a list of the functions that are called by the “this.Init” function, sorted by their average performance.
• Now, try it with your own web application! Just browse to the site and then return to the Ajax View main page to see the statistics.

How It Works

Ajax View works by using a proxy to intercept and rewrite the JavaScript code of a web application and automatically inject instrumentation code.  The rewriting is controlled by one or more instrumentation policies, embedded within the proxy.

In this demo, you have seen a simple performance profiling policy that adds log statements to the beginning and end of every script block and function definition within the JavaScript code of a web application.  This rewriting policy takes a script that looks like:

And turns it into a script that looks like:

Our prototype actually does a little more rewriting than is shown here.  For example, it inlines the logging functions to reduce performance overhead, rewrites return statements, and keeps track of the line number and character offset of the function to help identify anonymous functions and disambiguate functions with the same name.

Whenever the injected instrumentation logs an event, such as a function enter or exit, the event is timestamped and added to a queue. A timer event handler periodically empties the queue of messages and reports them back to the proxy via an HTTP post request.  The proxy is responsible for analyzing the results and generating the per-function performance statistics.

Conclusion

You have used the Ajax View proxy to gather performance profile information for a web application, without modifying the original web application, and without installing any extra plugins, ActiveX controls or extensions in the web browser.

As Ajax View is currently an early research prototype, we are considering several future directions for the project, including further research into instrumentation policies to help developers debug their application, and the possibilities of integrating this technology into developer tools and/or web server infrastructure.

• ajaxview@microsoft.com

• Microsoft Visual Studio AJAX Profiling Extensions Power Tool
• Ajax View JavaScript Instrumentation Proxy (first release of our client-side prototype)