WAS性能问题常用分析思路

1. Can the problem be demonstrated by running a specific test case or a sequence of events?

2. Is the slow performance intermittent?

3. Does it become slow, then disappear for a while?

4. Does it occur at particular times of the day or in relation to some specific activity?

5. Are all, or only some, operations slow?

6. Which operation is slow? For example, elapsed time to complete a transaction, or time to paint the screen?

7. When did the problem start occurring?

8. Has the condition existed from the time the system was first installed or went into production?

9. Did anything change on the system before the problem occurred (such as adding more users or upgrading the software installed on the system)?

10. If you have a client and server operation, can the problem be demonstrated when run only locally on the server (network versus server problem)?

11. Which vendor applications are running on the system, and are those applications included in the performance problem? For example, the IBM WebSphere Application Server?

12. What effect does the performance problem have on the users?

13. Which part of your analysis made you decide that the problem is caused by a defect in the SDK?

14. What hardware are you using? Which models; how many CPUs; what are the memory sizes on the affected systems; what is the software configuration in which the problem is occurring?

15. Does the problem affect only a single system, or does it affect multiple systems?

16. What are the characteristics of the Java application that has the problem?

17. Which performance objectives are not being met?

18. Did the objectives come from measurements on another system? If so, what was the configuration of that system?

Two more ways in which you can help to get the problem solved more quickly are:

1. Provide a clear written statement of a simple specific example of the problem, but be sure to separate the symptoms and facts from the theories, ideas, and your own conclusions. PMRs that report “the system is slow” require extensive investigation to determine what you mean by slow, how it is measured, and what is acceptable performance.

2. Provide information about everything that has changed on the system in the weeks before the problem first occurred. By missing something that changed, you can block a possible investigation path and delay the solution of the problem. If all the facts are available, the team can quickly reject those that are not related.

——from IBM Diagnostics Book