| Oracle® Containers for J2EE Servlet Developer's Guide 10g (10.1.3.1.0) Part Number B28959-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Servlet Developer's Guide 10g (10.1.3.1.0) Part Number B28959-01 |
|
|
View PDF |
This chapter provides programming tips for how to maximize the efficiency and performance of your servlets—general suggestions as well as suggestions regarding sessions, security, and thread models. There is also an introduction to the Oracle Dynamic Monitoring Service (DMS) to monitor performance. The following topics are covered:
This section discusses considerations when using sessions:
There are performance implications related to how session state is replicated in a distributable environment. Replication is triggered each time there is a setAttribute() call on the session object, so large numbers of such calls in a servlet may impact performance.
For performance reasons, OC4J does not wait to confirm successful replication of session state.
See the Oracle Containers for J2EE Developer's Guide for information about clustering in OC4J.
The following are considerations for the security of your Web application running in the OC4J servlet container:
In the global-web-application.xml file or orion-web.xml file, verify appropriate settings as reflected in the <jazn-web-app> subelement of <orion-web-app> to configure the OracleAS JAAS Provider and Single Sign-On (SSO) properties for servlet execution. These features must be set appropriately in order to invoke a servlet under the privileges of a particular security subject. You can edit them through the jaznWebApp property in the Application Server Control deployment plan editor, as described in the Oracle Containers for J2EE Deployment Guide.
OC4J includes standard support for security constraints and security roles through the <security-role> element of the web.xml deployment descriptor. For general information, refer to the servlet specification. OC4J also offers related support through the global-web-application.xml file <security-role-mapping> element.
Invocation by class name should be considered only in a development environment, because there is a significant security risk when users are allowed to invoke servlets in this way.
Invocation by class name can bypass standard security constraints unless this is specifically addressed in the web.xml file. In addition, when a servlet is invoked by class, any exception it throws may reveal the physical path of the servlet location, which is highly undesirable.
To resolve security issues, particularly in a production environment, you can disable servlet invocation by class name in either of two ways:
Set the system property http.webdir.enable to a value of false. This setting results in any servlet-webdir setting being ignored. (See the Oracle Containers for J2EE Configuration and Administration Guide for general information about OC4J system properties.)
Set a servlet-webdir value of "" (empty quotes), either through global-web-application.xml or orion-web.xml. This is editable through the servletWebdir property in the Application Server Control deployment plan editor.
(Invocation by class name is described in "Invoking a Servlet by Class Name During OC4J Development", including additional information about servlet-webdir settings.)
The following configuration in orion-web.xml, for example, would disable invocation by class name:
<orion-web-app ... servlet-webdir="" ... > ... </orion-web-app>
To guard against the guessing or "hacking" of session ID numbers for destructive purposes, OC4J uses java.security.SecureRandom functionality to generate random session ID numbers.
For additional information, also see the reference documentation under "Elements and Attributes of orion-web.xml, global-web-application.xml".
For a servlet in a nondistributable environment, a servlet container uses only one servlet instance for each servlet declaration. In a distributable environment, a container uses one servlet instance for each servlet declaration in each JVM. Therefore, a servlet container, including the OC4J servlet container, generally processes concurrent requests to a servlet by using multiple threads for multiple concurrent executions of the central service() method of the servlet.
Servlet developers must keep this in mind, making provisions for simultaneous processing through multiple threads and designing their servlets so that access to shared resources is somehow synchronized or coordinated. Shared resources fall into two main areas:
In-memory data, such as instance or class variables
External objects, such as files, database connections, and network connections
One option is to synchronize the service() method as a whole; however, this may adversely affect performance.
A better approach is to selectively protect instance or class fields, or access to external resources, through synchronization blocks.
As perhaps a last resort, the servlet specification supports a single-thread model. If a servlet implements the javax.servlet.SingleThreadModel interface, the servlet container must guarantee that there is never more than one request thread at a time in the service() method of any instance of the servlet. OC4J typically accomplishes this by creating a pool of servlet instances, with a separate instance handling each concurrent request. This process has significant performance impact on the servlet container, however, and should be avoided if at all possible. Furthermore, the SingleThreadModel interface will be deprecated in version 2.4 of the servlet specification.
For general information about multithreading, see the Sun Microsystems Java Tutorial on Multithreaded Programming at the following Web site:
http://java.sun.com/docs/books/tutorial/essential/threads/multithreaded.html
You can create one or more custom thread pools for selected applications to use instead of the default thread pool.
You create a custom thread pool in the server.xml file and then you make it available for applications to use by referring to it in one or more *-web-site.xml files.
Creating a Custom Thread Pool
To create a custom thread pool, add a <custom-thread-pool> element to the server.xml file. The <custom-thread-pool> element is a sub-element of the <application-server> element.
The name attribute is required, all other attributes are optional. The <custom-thread-pool> element has the same attributes as the other thread pool elements discussed in Chapter 10, "Task Manager and Thread Pool Configuration", of the Oracle Containers for J2EE Configuration and Administration Guide. The server.xml file is discussed in the "Overview of the OC4J Server Configuration File (server.xml)" section of Appendix B, "Configuration Files Used in OC4J" of the Oracle Containers for J2EE Configuration and Administration Guide.
The following example creates a custom thread pool named mypool in the server.xml file. The example specifies the following for mypool:
The minimum number of threads to create in the pool is 10.
The maximum number of threads that can be created in the pool is 100.
The number of requests outstanding in each queue can be 50 requests.
Idle threads are kept alive for 700 seconds.
<application-server ...> ... <custom-thread-pool name="mypool" min="10" max="100" queue="50" keepAlive="700000" debug="true"/> ... </application-server>
Assigning a Custom Thread Pool to Applications
To instruct applications to use a custom thread pool instead of the default thread pool, add a reference to that custom thread pool in the custom-thread-pool attribute in the <web-site> element in one or more *-web-site.xml files.
Each web application assigned to the web site and port specified in the *-web-site.xml file by being named in a <web-app> element will use the custom thread pool named in the custom-thread-pool attribute.
The *-web-site.xml file is discussed in the "Overview of the Web Site Configuration Files (*-web-site.xml)" section of Appendix B, "Configuration Files Used in OC4J" of the Oracle Containers for J2EE Configuration and Administration Guide.
The following example shows the custom-thread-pool attribute used to name the mypool custom thread pool to be used by all applications named in the <web-app> elements of the srdemo-web-site.xml file:
<?xml version="1.0" ?>
- <web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/web-site-10_0.xsd"
port="12501" protocol="ajp13" display-name="SRDEMO Web Site" custom-thread-pool="mypool" schema-major-version="10" schema-minor-version="0">
<default-web-app application="default" name="defaultWebApp" root="/j2ee" />
<web-app application="system" name="dms" root="/dmsoc4j" access-log="false" />
<web-app application="system" name="JMXSoapAdapter-web" root="/JMXSoapAdapter" />
<web-app application="default" name="jmsrouter_web" load-on-startup="true" root="/jmsrouter" />
<web-app application="ascontrol" name="ascontrol" load-on-startup="true" root="/em" />
<web-app application="bc4j" name="webapp" load-on-startup="true" root="/webapp" />
<web-app application="SRDEMO" name="SRDEMO-WEB" load-on-startup="true" root="/SRDEMO" />
<access-log path="../log/default-web-access.log" split="day" />
</web-site>
This section summarizes issues, mostly documented elsewhere in this manual, that may impact performance:
Consider the optimal expiration setting for Web pages in your application. You can set the expiration for pages that match a given URL pattern, as reflected in the <expiration-setting> subelement of <orion-web-app> in global-web-application.xml or orion-web.xml. A more appropriate setting decreases load on the application and improves performance. This is editable through the expirationSettings property in the Application Server Control deployment plan editor, as described in the Oracle Containers for J2EE Deployment Guide.
Be aware of performance implications relating to how multiple concurrent requests are synchronized or coordinated, and also be aware of related considerations regarding thread models. See "Considerations for Thread Models".
Servlet configuration parameters can significantly affect performance. In particular be careful in using File Modification Check Interval, as reflected in the file-modification-check-interval attribute of the <orion-web-app> element in global-web-application.xml or orion-web.xml. This is configurable through the Application Server Control Console Configuration Properties Page (documented in "Configuration Properties Page") or through the fileModificationCheckInterval property in the Application Server Control deployment plan editor.
Also be wary of the use-keep-alives attribute of the <web-site> element in default-web-site.xml. This attribute is discussed in the Oracle Containers for J2EE Configuration and Administration Guide.
Additional JSP-related configuration parameters can significantly affect performance, particularly the simple-jsp-mapping and enable-jsp-dispatcher-shortcut attributes of the <orion-web-app> element in global-web-application.xml or orion-web.xml. These are configurable through the EnableJspDispatcherShortcut and simpleJspMapping properties in the Application Server Control deployment plan editor.
OC4J in a standalone environment supports a mode of "shared" operation for a single application through multiple Web sites, where a site is defined as a particular host and port. This feature is particularly intended for secure applications in which some but not all communications require HTTPS. Running the noncritical communications through an HTTP port improves performance. You can enable this feature through the shared attribute of the <web-app> element in default-web-site.xml.
If you ever use standalone OC4J as a production environment (although this is not typical), ensure that the check-for-updates flag in the <application-server> element in server.xml is turned off. This parameter is discussed in both the Oracle Containers for J2EE Configuration and Administration Guide and the Oracle Containers for J2EE Deployment Guide.
For further information, also see the reference documentation under "Elements and Attributes of orion-web.xml, global-web-application.xml".
This section includes information about monitoring the performance of servlets.
In an Oracle Application Server environment, the Dynamic Monitoring Service (DMS) adds performance-monitoring features to several components, including OC4J. The goal of DMS is to provide information about runtime behavior through built-in performance measurements so that users can diagnose, analyze, and debug any performance problems. DMS provides this information in a package that can be used at any time, including during live deployment. Data are published through HTTP and can be viewed with a browser.
Standard configuration for DMS modules is reflected in the OC4J system-application.xml file and the default-web-site.xml file. In system-application.xml, the Web module dms and the path to its WAR file is specified. The default-web-site.xml file specifies that this Web module is deployed to the OC4J default application and binds it to its context path. Do not directly alter any of these DMS configurations.
Use Application Server Control to access DMS, display DMS information, and, if appropriate, alter DMS configuration.
Refer to the Oracle Application Server Performance Guide for information about DMS, the Oracle Containers for J2EE Developer's Guide for information about the global application.xml file (which uses the same specification as the orion-application.xml file), and the Oracle Containers for J2EE Configuration and Administration Guide for information about Web site XML files.
