Performance testing terminology

Performance testing terminology
Performance Analysis for Java Web Sites is one of my favorite resources for understanding and explainingperformance measurement basics. Someone asked me recently if I thought this book was dated, since it hasbeen out for several years. Regardless, the information is as valid today as it was a few years ago. The basicshaven't changed (the tools have, of course), and having the right foundation is important for communicatingwith our clients and among ourselves.
I try to be pretty consistent with my terms, and tend to repeat them over and over again within specificperformance situations. Usually within a day or two, everyone starts using the same terminology. Not tosimplify it too much (there is much more then I can describe here), but there are three specific measurementsthat can help cement your thinking with the right vocabulary. People new to performance terminology oftenget these confused or have different ideas about what they mean. Let's clear it up:
Load is the amount of pressure against a Web site. This always makes me think of a water hose, eitherturned down to a trickle or turned all the way up to full blast. With Web sites, we talk about load interms of concurrent users, which does not necessarily mean that every user is requesting a page at theexact same moment, which is a common misconception. It is better to think about load over time; forexample, a number of users accessing the site within a specific time frame, perhaps over five minutes orper hour.
Response time is the time it takes for the portal or site to respond to the request. This is reallyend-to-end time from the browser's perspective, and does not normally include time spend by thebrowser generating or displaying the page. Consider that response time generally will change (it willprobably increase) as the load against the site increases, potentially increasing to the point where it isunacceptable to users. Response time is one measurement that gets a lot of attention, and tuning yourportal to provide a consistent response time range with the expected volume of user load is yourultimate goal. Response time goals are chosen to follow industry standards; for example, a goal for thesite might be to respond to 95% of page requests within five seconds.
Throughput is the rate at which a portal can respond to requests. Generally, we think of this as eitherthe hit rate or page rate of the system, with the page rate measurement being more consistent.Throughput, coupled with response time and a model of your users' activity, can help you determinehow many users your system can handle (load) within a given timeframe. Throughput is often measuredin relation to load, determining where the boundaries of the system might be as user load continues togrow.