9.2 Diagnostic information collection and analysis

---

9.1 Problem determination methodology

The problem determination and performance tuning are closely related topics. It is important to understand the difference between problem determination and performance tuning.

Problem determination is the process of determining the cause of a problem, while performance tuning is the process of changing/adjusting a system or an application to perform in a more efficient way.

We should follow performance tuning routines/guidelines throughout the software development life cycle, right from the beginning of understanding the system requirements, analysis, design, coding and implementation. Irrespective of all the guidelines, no system is perfect. Even though you have designed a perfect system, with the passage of time requirements start changing. Workload on a system increases, and a time comes when applications start giving poor response. This is the point when we initiate the diagnostics process to find out the reasons of performance degradation and take appropriate measures against them.

Basically there are no fixed rules or best guidelines for problem determination. It all depends upon the user experience, kind of environment, and expectations from the system.

Sometimes fixing one problem may lead you into ten new problems, so it is always better to have an understanding of the overall architectural design of the system so that before applying any change you can draw a picture of all the other possible areas that are going to be effected by your corrective measures.

Here we describe the procedure for identifying the problem, analyzing the problem, finding the root cause of the problem, and then taking corrective measures to solve it.

Figure 9-1 on page 339 explains the steps of the problem-determination methodology that we are going to follow in our scenarios.

Figure 9-1: Problem determination methodology

Below we review the above figure.

1. Try to listen and understand the problem. No action is fruitful without understanding the pains of the end user. Apart from the regular routine-based performance tuning process, generally we come to know about a problem by one of the following ways:

   1. Users starts complaining about poor response times, that connections are not stable, request time-outs, etc.

   2. Alert messages from performance monitoring/diagnostic tools.

   3. System resource monitoring tools start giving threshold indictions like page swapping in main memory, CPU consumption, page hits, etc.

   4. Sometimes expectation mismatch occurs when applications are not producing desired results.

2. Once you have a clear understanding of the problem it can be easily translated into objectives to meet. This step is very important because most of the times we start with different objectives and attain something else, which was actually never desired. Also, in this step you can set an expectation level of the end user. It helps to give a more realistic picture.

3. It is always advisable to document all the steps.

4. You should always have a fallback procedure. If something wrong happened you must be ready with undo scripts.

5. Analyze the problem and areas that are related to it. It's very much possible to have more than one factor involved in the tuning of a particular problem, or we can have multiple reasons for the same problem.

6. Identify the root cause of the problem. This will help you to isolate the main problem from the rest. The idea of problem determination in a DB2 UDB and WebSphere environment is to determine where the actual problem lies.

7. Once you have identified the main root cause of the problem, apply your best practices and compare the results with the stated objectives in step 2.

8. Problem determination and performance tuning is an iterative process. Just keep on improving things as much as possible. Make sure you are documenting all the procedures you have applied and your fallback scripts are in place.

---