Load Testing Your Installation

 

This topic explains why load testing of the installation is important, and provides an outline of the steps necessary to complete this testing.

This topic includes the following sections:

• Rationale

• Steps for Load Testing Your Installation

  • General Architecture

  • WebLogic Commerce and Personalization Servers and Campaign Manager

 

---

Rationale

BEA recommends that you establish an environment where you can load test the installation for the following reasons:

• Testing your prototype under load will help you validate design decisions that may significantly alter the performance of your application, while it is still early in the development cycle.

• Any tier within an n-tier architecture can dramatically affect application performance (hardware, database, clustering environment, application tuning parameters, and so on). Load testing your application whenever design changes are made provides a way to narrow down performance problems to a particular area.

• Testing early and often increases the likelihood that your site implementation will be successful and scalable.

 

---

Steps for Load Testing Your Installation

The recommended approach for load testing is to start with the simplest aspect of the installation and then move into areas of increased complexity. If you observe slow behavior in any portion of this testing process, you should begin a more thorough investigation into its causes.

General Architecture

First, perform the following steps to identify performance issues with your network, database, or other software that is independent of the WebLogic Commerce and Personalization Servers or Campaign Manager:

1. Test your database (independent of any Web components) to determine how well your schema and SQL work. Note any areas where the schema or SQL may not be optimized for performance. For more information about configuring database connection pools, see "Connection Pools" at http://download.oracle.com/docs/cd/E13222_01/wls/docs60/adminguide/jdbc.html

2. Test your network for sufficient bandwidth, and check that the TCP/IP parameters on the server's operating system can sufficiently handle the application load you expect. It is quite possible that the network is the slowest aspect of your deployment.

3. Test your Web server, ensuring that it has sufficient capacity to serve static HTML pages when many concurrent threads are running.

4. Most large applications are clustered, but keep in mind that a clustering environment requires resources to perform load-balancing tasks (that is, the HTTPD proxy plug-in). Ensure that you have enough resources available to meet application requirements. For more information, see "Configuring WebLogic Servers and Clusters" at http://download.oracle.com/docs/cd/E13222_01/wls/docs60/adminguide/config.html

5. Test your servlet engine by running a load test against a trivial servlet such as a HelloWorld servlet. If this simple servlet does not perform and scale horizontally (meaning that as you add Java Virtual Machines, performance increases accordingly), the performance problems you encounter may be related to an infrastructure or resource issue.

Note: WebLogic Server provides a number of servlet examples that are useful for these purposes. For instance, SessionServlet uses HttpSession to track the number of times a client has visited a servlet. There are additional example servlets for accessing databases, EJBs, and message queues. All these servlets are located in the $WEBLOGIC_HOME/samples/examples/servlets directory, where $WEBLOGIC_HOME is the directory in which you installed WebLogic Server.

WebLogic Commerce and Personalization Servers and Campaign Manager

Now, perform the following steps to identify performance issues with the WebLogic Commerce and Personalization Servers, and Campaign Manager:

Note: We recommend that you understand the tuning concepts in "BEA WebLogic Server Performance and Tuning" at http://download.oracle.com/docs/cd/E13222_01/wls/docs60/perform/index.html before proceeding.

1. Verify that your WebLogic Server database configuration is optimal. WebLogic Commerce and Personalization Servers make extensive use of the database. You should check that your connection pool is large enough, and verify that your database handles connection failures in an efficient manner. For example, you may want to increase the number of connections at start up, the wait time before requesting new connections, whether your pool can shrink, and so on.

2. If your site uses the Portal Framework, verify that each portlet is optimized for speed as follows:

   1. Avoid using forms in a portlet that update the data within the portlet. This causes the entire portal to refresh its data, which can be very time consuming.

   2. Place items that require heavy processing in an edit page or a maximized URL. If you do not, the portal must wait for the portlet to process, and this considerably slows down the eventual rendering of the portal.

   3. Avoid large amounts of data retrieval that can take significant time to process.

3. Test your application's components, starting from the data access layer. Then proceed toward the GUI one step at a time. Pay attention to performance and scalability differences at each component and between each layer of your application. Finally, do end-to-end testing from a browser-based load-testing tool.

4. Test the behavior and performance of your application under simulated, real-world conditions. (Many tools are available to help you do this.) Be sure to use both anonymous and logged-in users simultaneously.