www.bea.com code library downloads support.bea.com BEA logo

Performance Tuning Guide

 Previous Next Contents

Tuning JSPs and Servlets

JSPs are the front end of your application. When a customer requests a page on your e-business Web site, WebLogic Portal compiles the corresponding JSP into a servlet. In addition to servlets that come from compiled JSPs, WebLogic Portal provides a set of servlets for exchanging information between various components of the system.

For suggestions on tuning the compiling and updating for JSPs and servlets, refer to the following sections:

All of the recommendations in this document are in addition to the recommendations in the BEA WebLogic Server Performance and Tuning guide.


Precompile JSPs

For each of your Web applications that you deploy, you can determine when WebLogic Portal compiles JSPs:

By default, the sample Web applications for WebLogic Portal deactivate the JavaServer Page (JSP) precompile option.

To precompile JSPs for a Web application that is deployed as an expanded directory hierarchy, do the following:

  1. From the Web application's WEB-INF directory, open the weblogic.xml file in a text editor and find the following element:
  2. <context-param>

    Note: web.xml was changed to weblogic.xml in this release.

    Note: A patch for WebLogic Server 6.1 is required for this functionality to work. The patches are included in 60sp2rp2, 60sp2rp1,and 61sp2.

  3. In the <param-value> element, replace false with true. For example, <param-value>true</param-value>
  4. Save the file and restart the server.
  5. For information, refer to "Starting and Shutting Down the Server" in the Deployment Guide.

To precompile JSPs for a Web application that is deployed as a .war file do the following:

  1. Make a backup copy of the .war file.
  2. Create a temporary directory and copy the.war file to the directory.
  3. In the temporary directory, unjar the .war file by entering the following command:
  4. pathname¥jar -xf WarFileName

    For example:

    c:¥jdk1.3¥bin¥jar -xf tools.war
  5. Under the temporary directory, open WEB-INF¥weblogic.xml in a text editor and find the following element:
  6. <context-param>
  7. In the <param-value> element, replace false with true. For example, <param-value>true</param-value>
  8. Save weblogic.xml.
  9. Under the temporary directory, if the WEB-INF directory contains a subdirectory named _tmp_war, delete the _tmp_war directory. This directory contains compiled JSPs and you must remove them before you re-jar the .war file to ensure that WebLogic Portal recompile all JSPs the next time you start the server.
  10. Remove the old .war file from the temporary directory.
  11. Create a new .war file for the Web application by entering the following command:
  12. pathname¥jar -cf WarFileName *.*

    For example:

    c:¥jdk1.3¥bin¥jar -cf tools.war *.*
  13. Move the new .war file back to its original directory.
  14. Remove any other files in the original directory that may have been left over from previous .war extractions. For example, there may be a WEB-INF directory remaining from the last time you ran the Web application from the .war file.
  15. Restart the server.
  16. For information on shutting down and starting the server, refer to "Starting and Shutting Down the Server" in the Deployment Guide.

The server console logs a message for each file it compiles. Ignore any [JSP Enum] no match messages. These are displayed for files that do not match the .jsp file extension.


Specifying a Java Compiler for a Web Application

The WebLogic Server Administration Console specifies a Java compiler for each server configuration. All applications that you deploy on a server use this compiler unless a Web application's weblogic.xml file specifies a different compiler.

To review the current Java compiler for your server, in the left pane of the WebLogic Server Administration Console, click a server. In the right pane, on the Configurations tab, click the Compilers subtab.

To specify a Java compiler for a Web application, do the following:

  1. Open Web application's WEB-INF/weblogic.xml file in a text editor.
  2. In weblogic.xml, find the following element:
  3. <--

  4. Remove the <-- and --> comment tags.
  5. Change the <param-value> to specify the pathname of the Java compiler that you want to use for the Web application.
  6. To deploy any modifications to this file, you must restart the server.

Adjust the Intervals for Checking JSP and Servlet Modifications

You can specify how frequently a server checks for modifications to JSPs and source files for other servlets in a Web application.

The sample Web applications check for modified JSPs each time a Web browser requests a JSP. Likewise, each time the server sends a request to a servlet in a sample Web application, it checks for any modifications to the servlet class files.

For your production Web site, you can decrease the amount of time in which WebLogic Portal serves JSPs and processes requests to servlets by increasing the intervals at which the server checks for modifications.

Although the server performs faster with higher values for the modification-check intervals, the higher values reduce sensitivity to changes in your source files. For example, you can set the server to check for JSP modifications every 10 minutes. After you change a JSP, it will take up to 10 minutes for the server to see the modifications.

This section includes the following topics:

About the Page-Check Intervals Properties

The pageCheckSeconds attribute determines the interval at which a server checks to see if JSP files in a Web application have changed and need recompiling. Each Web application defines this property separately in its WEB-INF¥weblogic.xml file. For example, the e-commerce sample Web application defines this property in the following file:

The following excerpt from the e-commerce sample Web application shows the pageCheckSeconds attribute with the default value in boldface text:


Note: The page-check interval does not determine the frequency with which a server checks for updated content that is stored in the database and in a content management system. Instead, the TTL (time-to-live) settings for various caches determine the refresh rate for content. For example, if you set the page-check intervals to once a second, and you set the TTL for the content cache to 10 minutes, it can take up to 10 minutes for the server to see the new content, even though it is checking for new JSP source code every second. For information on setting TTL properties for caches, refer to Chapter 4, "Using Caches."

To Adjust the Intervals

To determine the optimal page-check and reload-servlet intervals for your production Web site do the following:

  1. Establish performance baselines by testing WebLogic Portal performance with the interval set to -1 (which specifies that the server never checks for modifications).
  2. Test the performance with the interval set to various numbers of seconds. For example, set the interval to 600 seconds (10 minutes) and test the performance. Then set the interval to 900 seconds and test the performance.
  3. Choose an interval that provides the best performance while checking for modifications to JSP files and servlet classes at a satisfactory rate.


 Back to Top Previous Next