In the May 2007 issue of this magazine, Sean Chandler presented an excellent article titled "The Performance Problem" (article ID 20893 at SystemiNetwork.com), where he states that "we are operating in an industry addicted to server performance." He goes on to discuss that in the computer industry, there's a perceived need for "increased amounts of performance," that it's "often purchased in larger amounts . . . than was intended," and that a "great deal of time is spent . . . to obtain . . . and use performance." To his credit, Sean admonishes users to not buy more than they can use. That view may not make him popular among the chip manufacturers and hardware sellers, such as Big Blue, that appear to be focusing more on being a commodity supplier rather than an integrated manufacturing, development, marketing, technical support, and maintenance provider (which is the horse they rode in on years ago; however, that's another story).

To provide another perspective for the interested reader, I'd like to offer my two-cents' worth by discussing some of what I've observed in a quarter century of S/38-AS/400-iSeries-System i performance analysis and consulting. By shedding some light on what the term "computer performance" may mean to different people, I intend to give service providers and customers an understanding of precisely what some folks might miss in a conversation about computer performance: primarily, what performance is and how its definition may vary depending on a person's point of view.

So Just What Is Performance?

There are a number of ways to look at performance. You can define performance by hardware specifications, user expectations, and operational requirements. Hardware specifications are straightforward "feeds and speeds," for example:

• For the CPU: the chip frequency, number of processors, size of the CPU caches, Fetch/Store width to/from main memory, parallelism within a single processor, miniaturization, and technology used
• For main storage: the amount, speed, data access widths, and architecture (such as the type of parity checking or page frame protection)
• For the disk: the number of arms, amount of storage, rotational delay time, data recording scheme, and disk error-checking, recording, and recovery schemes
• For communications: the line speed, packet width, and error-recovery capability

Computer users are more likely to view performance as related to their individual operational objectives and priorities. Minimizing response time is often their most important consideration. Every transaction that arrives is the most important one to finish . . . ASAP. In addition to minimizing response time, users may also care about maximizing throughput. The system must respond fast enough (but not necessarily lickety-split) so that each user can complete a specific amount of work in a given time. Fast batch throughput may also matter, especially if there is time-dependent processing at the end of the normal workday. Often there's a direct relationship between how long it takes batch to run and how much interactive work preceded it. Another user requirement may be to minimize individual job runtime. Similar to fast interactive response time, it's an attempt to give any job all the resources it needs and prevent other jobs from contending for its resources.

Those accountable for system procurement and overall installation operational responsibility may view performance differently from the user. They may be more concerned with maximizing resource usage: Make the machine run at 100 percent busy all the time; otherwise, you're wasting resources and money. This definition most likely would come from the "business" people who are looking only at costs and trying to minimize them (sound familiar?). Another concern of those with operational responsibility is to ensure excess processing capacity. Are there occasional high peak-load demands? Do they require a specific level of throughput and response time? If you've ever tried to call the local power company right after an electrical power failure or an insurance company system after a tornado or hurricane, you'll understand this performance issue — their staff can't handle the load without a very large variation in response time. Keep in mind that the throughput and response time characteristics will vary non-linearly. They depend on system resource usage (resources being defined as CPU, disk, memory, com lines, and so forth — those things that your jobs need to run). They also depend on the load put on the system, which varies depending upon the business requirements. Regardless of how you define performance, it probably isn't always as good as you want it.Other computer performance requirements that may be important to either users or operational staff can be compared to buying a car, a microwave, or a snowblower:

• efficiency (30 miles per gallon)
• acceleration (0-60 mph in 3.3 seconds)
• capacity (carries four passengers very comfortably)
• stability/predictability (50,000 miles between oil changes, tires last 125,000 miles, 10-year manufacturer's full and unlimited warranty)
• self-tuning (thermostatically controlled heated seats in both front and back passenger compartment)
• extendibility (a microwave that heats the coffee water in 10 seconds)
• adaptability to heavy load (for Minnesotans, a snowblower that can move a four-foot-high band of wet, heavy snow left by the snowplow in your driveway without choking or stalling)
• Some may also care about minimizing variations (an airline actually meeting the on-time departure requirements) and consistency (the standard deviation of the performance metrics is equal to the average value).

Performance Wisdom

Performance should provide throughput and response times that are adequate, predictable, and consistent across various workloads, system usage, and applications. As the workload and costs increase, their ratio should be consistent, and performance should continue to meet the objectives. Back in March of 1999, NEWS ran some reader-submitted haikus. Keep this one in mind:

Buy a bigger box,
then things run very quickly
for a little while

If you're responsible for computer purchase, hardware configuration, or maintenance, you should ensure that everyone involved clearly understands what you want, what the user and business needs are, and what the potential performance solutions are.

Rick Turner is a retired IBMer and System i performance consultant based in Rochester, Minnesota. He has been involved in system performance since the early S/38 days. He has been a frequent speaker at COMMON, developed and taught IBM's Advanced Performance Analysis Workshop, and written many articles about S/38, AS/400, iSeries, and i5 performance. You can e-mail Rick at rtai01@attglobal.net.