My previous post focused on the contribution of the Database Administrator (DBA) to application performance. Even so, application performance depends upon many factors, some of which are beyond the control of even the most dedicated DBA. So if you were thinking of relying on your DBA to fix everything, this week’s performance principle provides is intended as a wake-up call:
Expecting a DBA to guarantee the performance of any application that uses the database is like asking a piano tuner to guarantee a flawless performance, regardless of the pianist.
The annual Computer History Museum Fellow Awards program publicly recognizes individuals of outstanding merit who have significantly contributed to advances in computing technology or applications, and to the evolution of the information age. Fellows may have worked in such diverse fields as hardware, software, networking, computer science, business, education, public service, or journalism, but they have one thing in common: their contributions have had a direct influence on computer history, and ultimately, they have changed our lives.
Each year around this time, a “who’s who” of the technology world assembles at the museum in Mountain View CA for a banquet and ceremony to induct a new group of Fellows. This evening, among the six new Fellows chosen in 2009, Don Chamberlin will be honored. Don was a co-inventor of SQL, the world’s most widely-used database language, and one of the managers of IBM’s System R project, which produced the first SQL implementation and seeded the development of much of IBM’s relational database technology.
In recent years, much has been written about the value of use cases and scenarios for capturing functional requirements; by comparison, their usefulness for performance management has received scant attention . An application scenario defined for performance management purposes:
Involves a known fixed workload
Runs in the normal production environment
Runs against the production databases
Is instrumented to record response time
Because standard application scenarios are application/program instances with defined behaviors, their use of computing resources is also (relatively) predictable. In a sense, they are “benchmark” programs, since they perform a similar function. Normally however, performance benchmarks are designed to mimic a particular type of workload on a component or system, and are used to measure system capacity and throughput when processing a typically broad mix of applications. Standard application scenarios, in contrast, can be designed to measure a system’s responsiveness for a single precisely-defined set of processing needs.
If Sir Isaac Newton were stating the laws of computer systems performance, his first law would surely have been: The graph of performance continues in a straight line unless the force of some external event causes it to change.
Not knowing what changed is a serious impediment to problem diagnosis.
How does performance suddenly become “abnormal”? Of course, the answer is, it doesn’t–at least, not on its own. There is always an external cause. So to fix a performance problem, we must find the cause–usually more of something, such as:
Increased processing volumes
More data in a database
More customers
A new application competing for resources
Increased competition from existing applications on the same servers
Increased interference from other traffic on the network.
