O'Reilly's Velocity 2011 Conference (http://velocityconf.com/velocity2011) is coming up this week. For the last couple of years it's been the scene of a very important reexamination of the issue of network-accessed application performance. Performance has been at the core of a lot of the infrastructure research we've done over the last decade and still an important area for further progress. Here's the story and why it isn't finished yet.
Over 30 years ago a seminal paper was published in the IBM Systems Journal (I'll send you a copy if you ask) in which standards for interactive program response were established to be in the range of .5 seconds (that's where the IBM data ran out). For the next 20 years, mainframe and minicomputer applications were designed to that standard.
Then the Web started to be used for commercial purposes. Early Web performance was pretty bad (20 second page load time), clearly unacceptable by the existing usability standards. But common sense said that 20 seconds was a lot better than (say) a couple of days to get something by USPS, so from that point of view 20 seconds was perfectly acceptable if less than perfect.
Then in 2001 Zona Research really messed things up publishing "research" that said, in effect, 8 seconds was OK. What the research showed was that if 8 seconds was the commercial state-of-the-art (true at the time) and your Web pages were delivered in 8 seconds, you wouldn't suffer commercially (all true, humans are tolerant). The problem isthat for a lot of the Web generation, 8 seconds was now the "rule," not .5 seconds and that just ain't right.
Thankfully at Velocity there has been an ongoing discussion about the true value of performance and what is really adequate. Two years ago Google and Microsoft presented some real experiment data that showed, chillingly, what the effect on user behavior if just a few tenths of a second of artificial delay were inserted into search requests (video).
And last year, Google's Urs Holzle gave a keynote that went a lot further (Velocity Presentation). He said the right performance target was really .1 second, and certainly not the 6 second page load times that Google believes is typical in the US. Then he went further to point out that the issue was not the access bandwidth (fiber to the home won't fix it) and that even if all the Web performance initiatives currently underway succeeded. the results would still be sub-par (perhaps 1.5 seconds). This doesn't mean that excellent performance for internet-connected applications is impossible, but rather that they need to have some client intelligence (given the speed of light compounded by the nature of TCP/IP and the Web). It's an accurate realization that simple thin-client solutions will never suffice, but given the power in modern devices and technology like HTML5 there are lots of solution approaches possible.
So what? Performance is still an unfinished story. There are far to many Web-based services with much less than ideal performance from the point of view of human usability.Two important tasks remain. First, we need to re-educate everyone on what excellent performance is (It turns out to be just what IBM identified in 1981.) Nothing since then has changed how humans read and think. The other open issue is getting more Web property owners to build enough performance logging and analysis infrastructure so they can see they relationship of performance to their business. In my experience when the relationship can been seen the importance of performance is clear; the issue is that too few business can measure these critical interactions.
Off to Velocity 2011!
