[ Team LiB ] Previous Section Next Section

Preparing for Performance and Load Testing

The idea behind testing is to execute your application in a setting that closely simulates the actual environment it will be running in. This means the following:

  • Reproduce the production application environment— This includes hardware and external resources such as your database environment

  • Attempt to accurately simulate actual user behavior— This includes determining the types of users who will be accessing the application and how they will be using it

  • Attempt to accurately simulate the number of actual users— This includes determining the maximum number of users per user type that will simultaneously be accessing the application

  • Stress testing— Monitor application behavior as dependent resources such as database connections and memory are denied

It is a good idea to think about the performance of the system right from the beginning—in the design phase. In fact, it is important to collect as much information as possible about the expected usage load of the system, and what expectations exist with regard to performance-related metrics such as response times before design begins. Having this information will be critical for making design decisions, and will facilitate the design of the performance and load tests.

Simulating User Behavior and Working with Business People

An important part of testing is to simulate user behavior. Software development does not occur in a vacuum. Applications are created to automate tasks and to enable employees and customers. Individuals outside of the software development department are usually responsible for the initial conception of new projects. They are integral in determining functional specifications because they have intimate knowledge of how users will access the application. Therefore, they should be very involved in determining performance goals and simulating user behavior. Although it is tempting for software developers to predict user behavior, this responsibility falls more squarely on the shoulders of the business people who have been involved with the application from its inception.

Determining When to Performance Test

Performance testing our application can uncover potential problems at various stages of development. The earlier that problems are uncovered is directly related to the amount of time and resources that must be spent to correct them, as depicted in Figure 25.1. This means that performance testing should occur

  • During Design— As an application is designed, architects and developers have many technologies and architectures available to them to meet functional specifications. Each technology and architecture carries associated performance costs. It is important to balance performance with architectural issues, such as code reusability and flexibility enabled by necessary levels of abstraction and encapsulation.

  • During implementation— As application code is tied together to perform larger tasks, performance testing should take place. It is possible that various code combinations will cause performance to suffer. Testing at this phase can pinpoint those areas if they exist.

  • Before deployment— After the complete application has been assembled, performance testing should be carried out using the actual production environment with simulated user load.

Figure 25.1. Finding problems early minimizes the time and resources that are spent to correct them.

graphics/25fig01.gif

The Validity of Benchmarks

Although numerous benchmarks have shown how WebLogic applications run under different hardware and software configurations, the applications being executed are very specific and are different from your application. Even though it is tempting to compare these applications to yours and intuitively determine how your application will perform, there is no substitute for your own performance testing. Because there are multitudes of factors that affect performance, such as hardware (including CPU and RAM) and software (including operating system and settings), you owe it to your users and yourself to performance test during design and implementation, but before you deploy your application in a live setting.

However, benchmarks can be useful when determining the running environment of your WebLogic applications. The most useful benchmark is ECperf. ECperf consists of representatives from many application server vendors such as BEA, IBM, and Sun Microsystems. Together, they have developed a specification and a toolkit for measuring the performance of J2EE application servers. More information about ECperf can be found at http://www2.theserverside.com/ecperf/index.jsp.

    [ Team LiB ] Previous Section Next Section