Managing Performance

So, what is performance management? The contextual way to answer this is to ask yourself, "Do I have, or have I had, performance problems with an application?" If the answer is "yes," then performance management is the discipline that would've ( potentially ) mitigated those performance issues.

Depending on whether you're facing this question proactively or reactively, essentially performance management is about the implementation of a performance methodology. It can be further explained as being the execution of the methodology to help identify performance problems (or hotspots); identify an optimization strategy; plan, tune and execute the optimization strategy itself; and, finally, analyze and monitor the system.

There are many industry-specific and even WebSphere-specific performance management models and methodologies. Depending on how fine-grained you like your models, many of these non-WebSphere specific models will suit the task accordingly ”one performance model fits all.

As depicted in Figure 1-3, once an optimization and performance management strategy is in place, the performance management model follows an ongoing, proactive life cycle.

Figure 1-3: Performance management model

Many times system managers implement processes to monitor or tune an environment but don't continue to review, follow up, and make changes where required. A system's characteristics are always changing and growing. Additional customer load, new functionality, and other non-application-specific factors will continuously change the face of your application environment.

It's therefore critical that the process outlined in Figure 1-3 is used continuously to ensure that an ever-changing system is managed for performance.

To highlight this point, Figure 1-4 shows the cost associated with resolving performance problems, both immediately and in the future. As depicted, the longer a performance issue goes unmanaged or unnoticed, the cost associated with resolving or mitigating that performance problem increases drastically.

Figure 1-4: Costs for mitigating performance issues, immediate and future

The increased costs come from a number of reasons; the most compelling is associated with the overall life cycle of the platform. That is, if a performance problem becomes apparent yet is left unnoticed or unmanaged, additional layers of application content and functionality will begin to hide the issue. And the longer it takes for you to find and resolve the issue, the more application code you'll probably need to change. Furthermore, the longer it goes unresolved , the more end users, physical systems, and platform complexity that it'll impact.

Note  

The issue of performance problems going unnoticed over time and the costs associated with resolving them in the future is similar to the timings associated with stress and volume testing during application development. The later in your software development life cycle you perform stress and volume testing, the more costly it'll be to uncover and resolve potential problems. For example, if you perform stress and volume testing after application integration testing and find performance problems, then the cost associated with fixing the issue is significant, compared with the cost in fixing the problem at the unit testing stage.

You'll now look at what's considered a valid performance improvement.