Google Chrome Creates Performance Measurement “Blind Spot”

As the adage goes, you can't manage what you can't measure—and it is increasingly challenging to measure performance of sophisticated applications running on the browser. Application Performance Management (APM) is grounded in measurements that relate as directly as possible to the user experience. The best metric is task response time—the time between when a user hits "enter" and the screen refreshes with sufficient information so the user can proceed with the application to the next task. There are many ways and places to measure response time. Some are true task times while others are representative or indicators of task time.

Today's tools measure in many places in the infrastructure using synthetic measurements or passive monitors, and they do it along the path between the user and the server. This gives us a wide range of tool alternatives each with a unique perspective on the performance picture. This rich variety creates an environment for innovation which has spawned more than 40 vendors of performance measurement tools or services.

The environment we are describing is based on a simple premise that network applications operate on a unique client-server paring with a recognizable traffic flow. If you can instrument that flow (or simulate is with a synthetic client) then you can measure many parameters relating to the user experience and delivery system health.

These client-server interactions have undergone a series of evolutionary stages.

  1. Terminal-host: the simplest model where the user inquiry is short, all of the application runs on the host (typically mainframe) and it delivers a simple response to the terminal.
  2. Client-server: the application execution is split into two places and sometimes there are several interactions (turns or chattiness) between the two to complete a task.
  3. Browser-server: this model is a step back towards the terminal days. The application operates on the server and instructs the browser to display complex results on the screen.
  4. Browser-network: Here the browser is instructed to get data from several servers so it can generate a rich media user experience.
  5. Application-network: Most if not all of the application is now running on the user's machine on top of the browser. The browser has become a vehicle that supports the applications with local services like Java machines, virtual machines, local storage, etc.

Stages 1 through 3 took about 40 years to evolve (1965 to 2005). During that long period APM tools could rely on a critical technical anchor: every user-network-application was completely defined by a single flow of bytes or packets which, if properly monitored, could be decoded to tell all we needed to know about the user experience. Stage 4 started to erode this anchor because the single flow turned into many browser-server flows. But clever instrumentation could still reconstruct most of the picture.

Stage 5 changes everything. All current measurement techniques are suddenly obsolete. You can't measure from a central location (e.g., datacenter), you can't see anything meaningful by "sniffing" the flow along the way, and you can't simulate the human user with a synthetic agent. None of the old techniques capture the real user experience or the real network load.

The new application-network paradigm introduced by next generation browsers like Google Chrome will have a completely different traffic profile. More traffic flows completely independently of the user's actions. Data is fed to the application and cached anticipating user demand to improve the user experience speed task response time. The trade-off is that each user session generates more traffic, most of which the user never sees.

The only location in the new paradigm you can reliably measure application response time is within the application. Will new-age applications come self instrumented so that service and business managers can track performance? We doubt it. APM is the last thing on Google's mind.

Just to make our message clear. Google does care about speed. The new applications that will operate on top of Chrome will be fast. However it is hubris to believe that everything will work well all the time. Some applications will perform poorly under some conditions some of the time. S**t happens. The most important letter in APM is M for Management. Managing complex systems to assure good performance for all users all the time is the big challenge.

Although we herald Google Chrome as a good development for the reasons we talked about yesterday, it creates a big new APM problem. We challenge Google to provide visibility into the new "blind spot" it helps create by following Chrome with a universal desktop application response time measurement tool.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2008 IDG Communications, Inc.

IT Salary Survey 2021: The results are in