Ajax Performance

What is a page? Part 3

Active measurement of web application performance involves simulating a real end user hitting a series of pages of the application and performing some action to move from one step to the next. An example transaction may start with a user loading up www.ebay.com, searching for ‘Beanie Babies’, and clicking the first result of the Beanie Baby search. That transaction would be 3 steps — home page, search results, and listing for the first search item. Organizations who perform this type of testing on their production applications have developed an understanding for how long each step should take and use this expectation to benchmark their product over time. This is the page-by-page model I discussed in Part 2.

So, along comes Ajax, blowing to hell all of our cozy institutional familiarity with measuring application performance. We need to update the model by adding in an understanding of the times perceived by the end user. In the old world, that was easy — the user clicked a link or submitted a form, the page refreshed, and the user waiting for content to finish loading. To provide an Ajax analogue, deconstruct the current model — the user takes an action, something happens, and the user receives a result. The whole page refresh thing goes out the window, but in its place we just need the flexibility to ascribe appropriately granular meanings to ’something happens’ and ‘user receives’ a result.

So, let’s now call a page of a transaction a ’step’, and let’s call a step:

Any user interaction that the developer considers a meaningful milestone within the business process.

The key word in there is developer. Historically, development hasn’t been very involved in performance testing, accepting the occasional load test. Ongoing performance testing has typically been the domain of the operations group. In the Ajax world, the developer is drawn into the performance discussion because no one else in the organization has a comparable understanding for how the user will interact with the application, where steps begin and end.

Also, Ajax developers are pushing more complexity to the edges of the networks, to the web browsers. In the past, it made sense for the operations group to have the exclusive focus on performance since most of what could contribute to degradation (servers, switches, upstream bandwidth) lived within operational control. If a database started to go wonky, operations would see it and get development involved. Ajax and the increasing reliance on third party content and code are making it harder to know how a site will perform once it goes live, so the era when developers could ship an application without doing rigorous performance testing is rapidly drawing to a close.

Our most mature customers design applications with this changing dynamic in mind. Developers build a testing plan for measuring the ’steps’ of the application, and this testing becomes release criteria for the application. Until a good user perceived experience can be demonstrated, the application doesn’t ship.