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:

• Precompile JSPs

• Specifying a Java Compiler for a Web Application

• Adjust the Intervals for Checking JSP and Servlet Modifications

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:

• You can specify that the application server compiles (precompiles) all JSPs when you start the server.

  When you activate the precompile option, the server startup process checks for new or modified JSPs in the Web application and compiles them. Activating the precompile option can cause a significant delay in server startup if you have modified or added JSPs but avoids delays when you access a new or modified JSP for the first time.

• You can specify that the application server compiles JSPs only when they are requested.

  With this option deactivated, the server starts quickly but must compile each new or modified JSP when you access it, causing a significant delay the first time you request a new or modified JSP.

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:

   <context-param>
     <param-name>weblogic.jsp.precompile</param-name>
     <param-value>false</param-value>
   </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.

2. In the <param-value> element, replace false with true. For example, <param-value>true</param-value>

3. Save the file and restart the server.

   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:

   pathname\jar -xf WarFileName

   For example:

   c:\jdk1.3\bin\jar -xf tools.war

4. Under the temporary directory, open WEB-INF\weblogic.xml in a text editor and find the following element:

   <context-param>
     <param-name>weblogic.jsp.precompile</param-name>
     <param-value>true</param-value>
   </context-param>

5. In the <param-value> element, replace false with true. For example, <param-value>true</param-value>

6. Save weblogic.xml.

7. 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.

8. Remove the old .war file from the temporary directory.

9. Create a new .war file for the Web application by entering the following command:

   pathname\jar -cf WarFileName *.*

   For example:

   c:\jdk1.3\bin\jar -cf tools.war *.*

10. Move the new .war file back to its original directory.

11. 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.

12. Restart the server.

    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:

   <--
   <jsp-param>
   <param-name>compileCommand</param-name>
   <param-value>java-compiler</param-value>
   </jsp-param>
   -->

3. Remove the <-- and --> comment tags.

4. Change the <param-value> to specify the pathname of the Java compiler that you want to use for the Web application.

5. 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

• To Adjust the Intervals

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:
PORTAL_HOME\applications\wlcsApp\wlcs\WEB-INF\weblogic.xml

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

<jsp-param>
<param-name>pageCheckSeconds</param-name>
<param-value>1</param-value>
</jsp-param>

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 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.