Ajax Performance

What is a page? Part 2

When I finished my presentation at the Ajax Experience Boston, one of the attendees asked if we (Gomez) run into problems educating our customers about approaches to understanding Ajax performance. It’s a good question; in the performance testing industry, years of experience with the page-by-page traditional model of developing and testing applications has lulled many into the mistaken assumption that certain metrics can be applied as benchmarks to all applications.

One such outmoded tool (the sliderule of the web development world, if you will) is the assumption that any page taking more than N seconds to load will lead to customer frustration and abandonment. Currently, N is defined as 7 and is determined by the mathematical function

N = 10 - (years since 2000 % 2)

The problem with this assumption, as touched on by Brad Neuberg in the article I mentioned in my previous post, is that any definition of load time that doesn’t include user perception is inherently flawed. A 12 second time to load all content isn’t an issue if the user sees an application ready for interaction in 5 seconds, with the rest of the Ajaxy bells and whistles being loaded behind the scenes. Isn’t that the whole point of the Ajax model, hiding as much network latency from the end user as possible?

Occasionally we’ll encounter a customer who wants to know the magic event fired by the browser at the point that the Ajax application is loaded, in the hopes of applying the 7 second benchmark. But there’s typically at least one developer or manager within the group who understands that the world doesn’t work that way anymore. Often, we’re helping that developer explain to management or the operations group why the higher total load time of the Ajax application is less important than the blisteringly fast user perceived load time the developer worked so hard to create.

The only way to define the performance of an Ajax application is to consider everything from the end user’s perspective. In the next (and perhaps last) post in the ‘What is a page?’ series, I will provide an Ajax-appropriate definition of page load time and explain how to use this metric to design, build, and release new applications.

A quick recommendation

As I mentioned in my presentation at the Ajax Experience Boston, the best article on Ajax performance tuning I’ve found is Brad Neuberg’s tutorial How to Profile and Optimize Ajax Applications. Brad lays out a compelling high level roadmap for understanding and managing performance while also providing specific optimization tips. Awesome stuff.

Ajax Experience wrap

It was a great conference, and it was an honor to have the opportunity to participate. This was my first conference presentation, and though the Girl Scouts of America were having a noisy throwdown next door, I was able to say my piece. I’m looking forward to Web Builder 2.0 in December. More details on that as we get closer to the date.

Back to the Ajax Experience — the conference seemed to me to show a technology marketplace in transition. Of course, the usual suspects were there — the doers and thinkers who have laid the foundation of Ajax, as well as leads from the Internet Explorer and Firefox teams. But the audience seemed to be more technically junior on average than I have seen at previous Ajax conferences. That’s really cool — it suggests increasing mainstream uptake and appreciation of accessibility, progressive enhancement, unobtrusive scripting, and all the other advances in sanity that DOM Scriptanistas and assorted Brainiacs on the Nerd Patrol have been pushing these past few years.

At Ajax Experience Boston right now

Gearing up for my presentation tomorrow morning at 9am in Grand Ballroom E.

I will post a wrap-up once the conference is over.

What is a page? Part 1

One of the benefits of working for a web performance testing company is that you work directly with customers who are pushing the boundaries of what is possible on the web. We started seeing our first proto-Ajax sites in 2003, though of course those were muddled messes of IE5+ proprietary code (DHTML Behaviors, anyone?). Fortunately, history hasn’t been kind to that approach, and the Ajax revolution of the last two years has been built on the pillars of W3C standards and graceful degradation.

We have made progress, and I believe Ajax is inevitable and nothing less than the future of the web. However, we are in the early days of adoption, and Ajax is still a relatively immature technology for commercial use. How can I tell? Let’s take a look at Ryan’s key indicators of immature technology:

• A fragmented landscape for the new developer The number of Ajax libraries outnumbers commercial Ajax sites. That’s cool — the zeal of the community is awe inspiring, and great work is being done to build out a broad and deep foundation for client-side development in the browser. So, choice is good, but too much choice is overwhelming to the senses. How is a web developer assigned to Ajaxify the existing portal by Joe PHB, CIO Magazine subscriber, to decide how to get her feet wet? In many cases she can’t, leading to…
• Reinventing the wheel There are a bewildering number of libraries on the market, none of which are established enough to demand the attention of the neophyte developer. And for the developer lucky enough to be assigned Ajax work, the temptation to cut teeth writing XHR code from the ground up is irresistible. At this point, I’m pleasantly surprised when I see a customer site that uses Prototype, Dojo, etc. Developers are writing their own apps from the ground up at least twice (make that thrice) as often as they are using existing libraries, in my experience.
• SLAs? What the hell are they? I was at an Ajax conference session earlier this year where a major web company was pitching their services for integration into commercial, for pay, mashups. I asked what guarantees they could offer about the service levels of their application since mashup builders would have real dollars riding on their performance (a hugely self-serving question for a web performance company employee to ask, I admit). The answer? “You can have an SLA, but it will cost you” along with some equivocation about how important performance is to them. If you ask the same question of DoubleClick or any other traditional web advertising provider, you will get a very different (and much more comforting) answer, and your contract will likely include clauses that amount to punitive damages if the provider can’t meet those guarantees. That’s a hallmark of a mature, commoditized space.

Immature is by no means a pejorative. Our current location on the tech adoption curve is wholly appropriate. These things take time, and implementing Ajax requires a significant shift in approach from web developers, testers, and operations groups. I think we are at the point where our early commercial adopters are starting to poke their heads up from developing their shiny new applications and wonder how exactly to apply their existing frameworks for understanding and managing those applications in production.

Over the coming days and weeks, I will talk about my experience working with customers who are making that shift. Hopefully, this discussion can help crystallize our collective understanding of managing Ajax apps.

Upcoming presentations

I will be delivering speeches about Ajax performance at:

• The Ajax Experience Boston — Boston, October 23-25
• Web Builder 2.0 — Las Vegas, December 4-6

In both of those sessions, I will be talking about performance management approaches for Ajax and highlighting the increased need for developer involvement in application management, a dramatic change from traditional web development where ongoing performance testing was almost exclusively the domain of the operations group.

As mentioned yesterday, I am actively working on my presentation. The Ajax Experience looks like a great setup for this type of talk — 6 parallel discussion tracks, 90 minute sessions, and a maximum capacity of 500. Seems like a nice, cozy environment.

java.net.URL considered annoying

The implementation of hashCode in java.net.URL has a quirk that tends to introduce subtle bugs into Java networking apps. Haven’t seen much discussion about this in the wild.

As implemented, hashCode uses the IP address of the URL hostname as part of its calculations. This leads to at least three annoying issues:

1. Calling equals on a URL or using it as a key to a Map is a blocking operation on a network call. It’s unlikely this is what you intended, but it’s easy enough to overlook until (e.g.) your primary name server dies and you wonder why all hash lookups are now taking 5 seconds. This is how I stumbled onto the issue years ago.
2. Calling equals on two URLs with identical paths and different hostnames will return true in the case that both hostnames map to the same IP. It can certainly be argued that this is intended behavior since the URLs point to the same network resource, but I’m guessing that most developers who call myURL.equals(yourURL) are expecting to get a string comparison, ala myURL.toString().equals(yourURL.toString())
3. Using a URL as a key into a Map may lead to a miss in a DNS round robin scenario where the same hostname maps to multiple IPs. This is, I think, the most insidious case as most URLs will hash properly until one day you discover multiple entries in a Map keyed to string-identical URLs.

My advice? Simple enough. Just use strings. When working on projects involving URLs, a useful internal convention is to use all capitals to designate a method that will return a URL and lower case for a method that will return a String representation of the URL, perhaps suffixing with String just to be absolutely clear. Example:

public interface HttpRequest {
   public URL getURL();
   public String getUrlString();
}

Also, generic collections make spotting abuse of this convention much easier in the Map cases. Code that does HashMap<URL, HttpRequest> has a very distinct odor and is much easier to sniff out at the source.

I’m back!

Wedding was lovely, Honeymoon was relaxing. Now I’m back and have had a couple weeks to get my feet back under me at work.

October is shaping up to be a very busy month with much business travel, and I’m also gearing up for my presentation at The Ajax Experience two weeks from Monday. The session will be a discussion of real world Ajax performance and the increased need for developer involvement in performance management. I will post more here as my presentation solidifies.