Performance of software applications can often be very subjective. An application that provides a two second response may be sufficiently fast to meet all driving business requirements of the task at hand. In addition, the application may be meeting all user expectations, as subjective as they might be. However, place a user in front of the same exact system with a one second response time and after several days any effort to use the slower system will probably be rated as unacceptable. In both cases, all business requirements, except perhaps subjective end user ratings, are equally met. The question is, do you now need to provide one second response time for all users?
As in the above example, the most important step to identifying performance problems is to have a well-defined benchmark of system performance to use as a reference. Given such a benchmark, future perceived performance problems can be compared against the benchmark metric to help determine if they are truly problems or changes in performance, versus subjective differences. Once you determine there truly is a performance problem, the next step is to identify the bottlenecks.