11.1 Performance Planning

I l @ ve RuBoard

Planning for performance is the single most important indicator of a Java 2 Enterprise Edition (J2EE) project's success. A performance plan does what any other plan does: it optimizes your chance of succeeding in a specific area of a project ”in this case, application performance. If you know that successful performance is not necessary for your project, you don't need a performance plan. My experience with projects that have no performance requirements is limited to college assignments. In business, I find that the importance of performance is second only to core functionality, and comes ahead of security, robustness, and secondary functionality such as add-ons that differentiate products.

A performance plan puts into place the structures and procedures that ensure you have made every attempt to achieve the performance goals of your project. It also improves the quality of a project, and decreases the risks of project failure. The simple act of defining a performance plan immediately increases the chances that your project will attain acceptable performance. Carrying through your performance plan by setting performance goals, measuring against those goals, and using the feedback to improve performance significantly improves the chances of a project's success.

11.1.1 Perform Initial Performance Planning

To initiate a performace plan for your J2EE application, you should set out the scope and performance objectives and define communications channels between all participating parties.

Performance reaches across all parts of a project. It is necessary to allocate responsibility for performance to one or more people who can look at individual components as well as the overall system. Performance analysis and feedback might require simple code changes, readjustment of the communications structure between components , or even refactoring of the design. This implies that the performance experts might need to communicate with team members about all aspects of the project.

It is not necessary for the performance experts to be project experts as well. Part of performance planning involves setting clearly defined goals (see the next section), and these goals, together with information generated using performance tools, help to clearly identify which aspects of the project are falling short of the targeted performance.

The performance experts should be responsible for maintaining the project's performance goals, and for identifying areas that need improvement. Performance experts should also be responsible for defining alterations to the project that will help to attain the performance goals. In summary, there are three separate performance responsibilities:

• Maintaining the project's performance goals (performance planning)

• Identifying areas of the project that fall short of defined performance goals (performance testing and analysis)

• Suggesting changes to the project that will help achieve the performance goals (performance tuning)

These three sets of responsibilities can be separated; it is not necessary for the same performance experts to be responsible for all of them.

11.1.2 Set Performance Targets

Regardless of where you are in your project, the first step in your performance plan should be to set performance targets. These should cover as many performance aspects as possible. Some of these include expected response times (e.g., "Any button click providing a new page should display in less than 2 seconds, except for queries . . . "), batch process times (e.g., "Nightly batch processing should not exceed 5 hours"), throughput (e.g., "The system should handle up to 60 transactions per minute within performance targets"), concurrency (e.g., "Up to 500 users can use the application at any one time").

Performance in most projects is seldom consistent. All sorts of procedures can interrupt processes. For this reason, it is usually better to specify a range of acceptable performance targets ”e.g., "Button click to page display response times should be less than 2 seconds in 90% of cases, and less than 5 seconds in 99% of cases." When specifying response time ranges for activities initiated by users, pay special attention to the 90% range. Users' perception of the average response times is actually close to the 90% value in the range of measured times. People give more weight to bad news, and their performance perceptions are no different.

Setting the performance requirements of your application is not necessarily a developer-level task. Your customers or business experts need to establish the response time that is acceptable for most functions the user will execute. It can be useful to start by specifying which response times are unacceptable.

With that in mind, let's review the performance-tuning best practices from Java 2 Standard Edition (J2SE):

• Include a performance specification in the project specification.

• Make the performance objectives clear by quantifying them.

• Agree on target times with users before tuning.

• Specify acceptable variations in performance targets.

• Pay attention to the target response time under which 90% of responses should lie, as this is the "average" reponse time perceived by users.

• Specify targets for the scaled system, including variations in user/data/object volumes .

I l @ ve RuBoard