Ajax stands for Asynchronous JavaScript and XML. In the end user monitoring world this translates to the good old days of basic single web page requests and web server responses going away. Today you can spend an hour or more working in an Ajax application and all you will see on the wire is one page request followed by hundreds of asynchronous calls, which in the case of a monitor are seemingly issued on behalf of that initial page. Before Ajax and other asynchronous technologies we had pages and hits where a bunch of hits made up a page that a user would see in their browser. These hits and pages were sent over http so our products would gather the hit requests and wait for the hit response before reporting the collected metrics back to the monitor. There was a bit of interpolation magic that we did to differentiate a page from a hit but for the most part our hit processing could group those together pretty well. With Ajax having pages and hits are not enough. If we were to continue monitoring as we do today we would see a single page with hundreds of page elements (Ajax requests) until some point where we eventually saw a new page request come across the wire. For most applications today that have small bits of Ajax on a page this isn’t a big bother but for those full blown asynchronous applications this would be a mess which would be very difficult to translate into something meaningful.
The solution our Quest architects are currently implementing focuses on treating an asynchronous request as another entity changing our solution from one that has pages and hits to one that has pages, hits, and asynchronous requests. In upcoming versions of our monitor we will offer functionality that has auto discovery of asynchronous requests developed in popular toolkits such as; Dojo, Google Web toolkit, Adobe Flex toolkit, and RMTP and also provide a wizard for direct configuration. The options in the direct configuration will include the ability to tell our end user processes how to treat specific asynchronous hits as identified by regular expression matching of the url or header field matching. The options for specific matched asynchronous hits would be:
- Treat a HTTP request as a page (This would be a good option to tag clicks)
- Treat a HTTP request as a hit on the page (These would be useful for requests that resulted from a mouse over)
- Treat a HTTP request as an asynchronous hit (These would be hits that are unrelated to the page or asynchronous requests that you wanted tracked separately)
These options will allow users to adjust the behaviors of their asynchronous application monitoring without having to rely on page instrumentation.
This is the first of a series of posts that we plan on for a continued discussion around Ajax and other asynchronous requests. In my next posting we will further explore the topic of asynchronous web requests and how it affects Quest visual session replay.