|dev2dev Home > dev2dev WebLogic Portal > e-docs WebLogic Portal 8.1 with Service Pack 3 Documentation > Performance Tuning Guide > Tuning JSPs and Servlets|
Performance Tuning Guide
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: 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. 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:
WEB-INFdirectory, open the
weblogic.xmlfile in a text editor and find the following element:
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
To precompile JSPs for a Web application that is deployed as a
.war file do the following:
pathname¥jar -xf WarFileName For example: c:¥jdk1.3¥bin¥jar -xf tools.war
WEB-INF¥weblogic.xmlin a text editor and find the following element:
WEB-INFdirectory contains a subdirectory named
_tmp_war, delete the
_tmp_wardirectory. This directory contains compiled JSPs and you must remove them before you re-jar the
.warfile to ensure that WebLogic Portal recompile all JSPs the next time you start the server.
pathname¥jar -cf WarFileName *.* For example: c:¥jdk1.3¥bin¥jar -cf tools.war *.*
.warextractions. For example, there may be a
WEB-INFdirectory remaining from the last time you ran the Web application from the
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:
<param-value>to specify the pathname of the Java compiler that you want to use for the Web application.
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(which specifies that the server never checks for modifications).
600seconds (10 minutes) and test the performance. Then set the interval to
900seconds and test the performance.
|Contact BEA Site Map Feedback Privacy Copyright © BEA Systems, Inc. All rights reserved.|