Response Time Standards for Web Sites and Web Applications
Availability, on the other hand, is a measure of a system's stability. It is not a performance metric, it is a software (or hardware) quality metric.
So, technically speaking, performance and availability are orthogonal issues. You would not call a London taxicab a high performance vehicle just because it runs for 300,000 miles without ever breaking down. Conversely, for broken software, or a car that will not start, performance measures are irrelevant.
Practically speaking, however, availability and responsiveness are interconnected concepts. How slow does a user interface have to be before the application becomes unusable, and might as well be completely unavailable? Slowness matters; how long will you wait before you click away? Maybe you'll come back later if you really need to see that page. If not, how often do you ever revisit a page that didn't load when you were interested in reading it?
Posing the question in this way reveals that performance and availability have a complicated relationship, one that involves business objectives, the user's experience, overall workload volumes, system scalability, and cost per transaction processed:
While availability is not actually a measure of performance, it certainly has an effect on performance:
- Unstable systems often have specific effects on performance in addition to the other consequences of system failure. For example, instability affects the average processing time of large batch workloads, because of the possibility of failures during processing.
- Additional processing is inevitable as users try to catch up with their work following a period of down time, thereby creating artificial peaks in the distribution of work, leading to higher system utilization levels and longer response times.
- Highly available systems ... usually invest in redundant hardware and software and impose a need for careful design that often benefits performance. In this case availability (and any improved performance) is being traded for cost.
This is one reason why I particularly like the analysis methodology underlying the Apdex [Application Performance Index] standard. Once you have defined a response-time target, an Apdex-compliant reporting tool allocates every measurement into one of just three zones: Satisfied, Tolerating, and Frustrated. Measurements in the Satisfied zone score a full point, those in the Tolerating zone score half a point, and those in the Frustrated zone score zero. Nothing. Zilch.
This post contains material first published in High-Performance Client/Server, Chapter 3: Performance Fundamentals, p61. Tags: Apdex, performance, availability, response time, download time, Performance Matters, Web performance