How you define good performance depends on your particular needs and priorities. Performance objectives should be realistic, in line with your budget, understandable, and measurable.
Response time represents the elapsed time between when a user submits an SQL request to a server (usually through an application program), and when the response arrives on the user's screen. It can also represent the elapsed time required to respond to an SQL request submitted from a batch application program.
The easiest response time objective to state is a maximum time, such as, "SQL queries will return in under 2 seconds". However, response times can vary for many reasons. So, include acceptable tolerances in your targets. For example, "SQL queries will return in under 2 seconds 80% of the time". This allows for unusual transactions that have exceptionally heavy processing or database access requirements.
Response time for any database transaction has three components. The SQL statement is generated in an application program; it travels through a network to an application server; and finally, the server generates a response, which is returned to the program through the network.
Application server response time represents the time it takes for the server to interpret your request and retrieve or update data. This can be affected not only by how well your database and SQL statements are designed, but also by how well the server's initialization parameters are tuned.
Network response time represents the communication delay between the application program and the application server. It also represents any delay between a user's terminal and the application program. This usually does not represent a large part of overall response time, unless your server and application program are physically separated by large distances.
Application program response time can often be the fastest part of the process, but do not overlook it. Some programs can take more time to process data than was required to retrieve this data from the server. For example, if you retrieve floating-point data that needs to be displayed in scientific notation, your program may take longer to perform the conversion than it took for the server to generate the answer set. Therefore, do not assume that if you double the speed of your server, your end users will see their response time cut in half.
You can also use a stored procedure (user-written application program that is compiled and stored at the server) to eliminate many of the network send and receive operations, and thereby reduce network cost of distributed database access. For more information on stored procedures, see the DB2 Server for VSE & VM Database Administration manual.
Throughput measures the amount of work processed over a period of time (refer to Workload). You can measure it either in a controlled test system or in a production system.
In a test system you are able to define representative workloads and measure how many of these transactions your system can complete per unit of time. For example, you can measure the number of transactions per second.
In a production environment, look for measurements that are effective as averages over time that will give you a rough indicator of throughput of your overall system, such as BEGINLUW. Also look at the throughput of your various subsystems -- for example, the pages processed per second by your DASD I/O system.
Availability is a measure of the proportion of time a system or resource is ready when it is required.
It is usually measured in hours, weeks, or months. For example, you may want to set an objective of 8 hours downtime (time when your server is unavailable) per month, based on a 24-hour day. Downtime is not necessarily caused by a malfunction. You may need to shut the application server down to apply service or perform maintenance.
If you do not have enough time to set performance objectives and to monitor and tune in a comprehensive manner, you can address performance by listening to your users. Find out if they are having performance-related problems. You can usually locate the problem, or at least where to start, by asking a few simple questions. For example: