Skip Headers

Oracle® Containers for J2EE Servlet Developer's Guide 10g Release 3 (10.1.3) B14426-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# 8 Best Practices and Performance

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:

- Best Practices for Sessions

- Best Practices for Security

- Considerations for Thread Models

- Best Practices for Performance

- Monitoring Performance

## Best Practices for Sessions

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.

## Best Practices for Security

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

## Considerations for Thread Models

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

## Best Practices for Performance

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

## Monitoring Performance

This section includes information about monitoring the performance of servlets.

### Oracle Application Server Dyn amic Monitoring Service

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.