Always analyze problems starting with the slowest resource and moving to the fastest. Thus, the first place to start is disks, then memory, and finally CPU efficiency. Before you begin to look at the system, you must make sure that the application is performing correctly. Correct application performance has the greatest effect on overall performance. This is easy to determine by looking at the number of database requests per user. If most users have tens of thousands of requests but a few users have millions of requests, you should ask those few users what they are doing with the system and look at those portions of the application for inefficiencies.
If these users are doing the same jobs as everyone else, the cause of the problem might be how they are using the application. This is more common with off-the-shelf applications than with custom applications. The business rules for the off-the-shelf application might not match your business process exactly. One example is an application that is written for companies with multiple divisions, but deployed at company with one division. The application expects the user to enter a division code as a unique identifier, but the employees at the single-division company, may not trained to enter a division code. The application might not have an index defined to find records efficiently without a supplied division code. While this can be rectified on the application side, you first must discover the problem before you can fix it. The solution might be to train users to enter a division code until an application modification can be made.
Once you have ruled out the application as a source of performance problems, you can start looking for common problems.
