|
DB2 UDB V8 and WebSphere V5. Performance Tuning and Operations Guide2004 Authors: Chen W. J. Published year: 2004 Pages: 13-14/90 |
| < Day Day Up > |
The following guidelines should help you develop an overall approach to performance tuning.
This is the basic law that most of the performance benefits usually come from initial efforts. While designing the system try to get the requirements/facts, like disk sizes, disk I/O rates, number of users, transaction and batch processing load on CPU, transaction rates, memory requirements, availability, network bandwidth, backup requirements. If not taken care of, these factors later on generally produce smaller benefits and initially require more effort.
Identify the primary cause of performance bottleneck. If you try to tune resources that have little or no effect on response time, it can actually make subsequent tuning processes more difficult. If there is any significant improvement potential, it lies in improving the performance of the resources that are major factors in the response time. The best approach is to tune identified constraints.
Even though you are sure that all the changes are going to be beneficial, do not change more than one performance tuning parameter at a time, otherwise you have no way of evaluating how much each change contributed . Changing one parameter at a time helps you to evaluate whether the change does what you want. Remember, every time you change a parameter to improve one area, you almost always affect at least one other area that you may not have considered .
Tune one level of your system at a time. This helps you to understand how much each area contributed. Consider the below-mentioned areas while tuning processes:
Hardware
Network
Operating system
Application server
Web server
Database manager
Application programs
SQL statements
Beyond some limits, software alone cannot help much for further performance improvements. You might need to add more storage, additional CPUs, more memory, or a combination of these.
Upgrading hardware is not an easy job inspite of good budget approvals from the management. You can spend money on additional disk storage only to find that you do not have the processing power or the channels to exploit it. So it is very critical to identify which portion of hardware should be upgraded. Also, upgrading hardware does not always work. Sometimes even additional storage or processing power cannot help much to improve performance.
Try to follow a proper performance tuning methodology and keep every step documented. Before applying any tuning step one must be ready with the scripts to revert that step. This saves a lot of time, as tuning is an iterative process and the possibility of applying same steps again and again usually remains very high.
| < Day Day Up > |
| < Day Day Up > |
Develop a plan for performance monitoring and tuning by taking the inputs from the user , and recognizing the limits of tuning in your system.
Performance tuning is an iterative process. Depending upon the result of monitoring, adjust the configuration of the hardware, operating system, database server, and application server, and make changes to the applications that use this infrastructure. Base your performance monitoring and tuning decisions on your knowledge of the kinds of applications that use the data and the patterns of data access. Different kinds of applications have different performance requirements.
Choose performance criteria and set performance objectives based on those criteria. The main overall performance criteria of computer systems are response time and throughput.
Response time is the elapsed time between when a request is submitted and when the response from that request is returned. Examples include how long a database query takes, or how long it takes to echo characters to the terminal, or how long it takes to access a Web page.
Throughput is a measure of the amount of work over a period of time. In other words, it is the number of workload operations that can be accomplished per unit of time. Examples include database transactions per minute, kilobytes of a file transferred per second, kilobytes of a file read or written per second, or Web server hits per minute.
Figure 1-5:
Performance tuning process
Performance tuning is primarily a matter of optimal resource management and correct system-parameter setting. Tuning the workload and the system for efficient resource use consists of the following steps:
Define performance objectives.
Determine how the results will be measured.
Quantify and prioritize the objectives.
Develop and execute a performance monitoring plan.
List the constraints, limitations, and boundaries of the system.
Identify the workloads on the system.
Identify the critical resources that limit the system's performance.
Minimize the workload's critical-resource requirements:
Use the most appropriate resource, if there is a choice.
Reduce the critical-resource requirements of individual programs or system functions.
Structure for parallel resource use.
Make one change at a time.
Repeat steps 4 through 7 until objectives are met or resources are saturated .
Apply additional resources, if necessary.
Every system has its own limitations and boundaries. Beyond certain limits you start releasing that even after putting a lot of efforts in tuning process only a small amount of efficiency benefits reaped from the system.
Try to consider how much time and money your management is ready to spend on improving system performance, and how much the end user will benefit from this process. Take care of budgets because sometimes significant performance improvement requires additional infrastructure, that is, you might need to add more disk storage, faster CPU, additional CPUs, more main memory, faster communication links, or a combination of these.
However, there is a point beyond which tuning cannot help. At this point, consider revising your goals and expectations within the limits of your environment.
| < Day Day Up > |
|
DB2 UDB V8 and WebSphere V5. Performance Tuning and Operations Guide2004 Authors: Chen W. J. Published year: 2004 Pages: 13-14/90 |