The proliferation of web hosting alternatives and client side execution of code within web browsers has moved APM vendors to take a much harder look at collecting data from within the browser using JavaScript instrumentation. While sniffing the wire to analyze HTTP packets and parsing web logs are still very viable solutions, web technologies continue to evolve, causing more and more metrics errors and problems to be missed. The biggest issue that we see today is less of the page is being loaded from source, meaning going back to the originating web server. In extreme cases, we have seen only 20% of the traffic served by the host website, going to the end user’s browsers, while the other 80% is served from accelerators and other content hosting technologies. The next biggest issue comes with asynchronous technologies like AJAX with a lot of the execution and the user experience happening right in the browser without any call backs to the web server(s). Additionally, there are other complications with data gathering as organizations turn to Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).
Quest will be diving further into this area of client side JavaScript in Foglight releases starting as early as Q3 of 2012. Today there is Foglight JavaScript available to measures page load times. The results from the executed scripts are gathered by the Foglight sniffer solution (FxM) and are used to augment other Foglight End User performance metrics that have been gathered through synthetic scripts, network sniffers, and web logs. Besides page load time there are many other things to consider with APM JavaScript. JavaScript can also gather navigation timing API data (made available with HTML 5), client side execution errors, DOM events like mouse and keyboard instructions, and eventually may be able to gather some of the newer more desirable metrics like “first paint” and “above the fold” times.
While all of these new collection abilities are interesting they, like most anything else, come at a cost. We’ve heard, from some of our customers, that APM and analytic JavaScript solution providers have required them to put hooks into their pages. This solution creates good and useful data but we’ve heard from several customers that the exercise of hooking HTML code has taken as long as 6 man months. We’ve also heard that more of the customers have abandoned the effort of hooking all together and would prefer to make do without the data. Overhead is another concern especially in mobile devices. Naturally executing a JavaScript costs something in the browser but where is that cost / value tradeoff becomes the next question. Beyond performance overhead and the management of the hooks, security, network volume, QA validation, insertion methods (injection versus manual) and JavaScript sprawl all keep folks up at night as more management vendors try to get their hooks into your web pages. At Quest all of these issues are being carefully considered as we move into our next release.
As always we’re very interested in your thoughts and concerns around this topic for those that wish to contribute…
