1. Overview of GlassFish Server Performance Tuning
Avoid Serialization and Deserialization
Use StringBuilder to Concatenate Strings
Assign null to Variables That Are No Longer Needed
Declare Methods as final Only If Necessary
Declare Constants as static final
Declare Method Arguments final
Synchronize Only When Necessary
Use DataHandlers for SOAP Attachments
Java Server Page and Servlet Tuning
Avoid Shared Modified Class Variables
Monitoring Individual EJB Components
Remove Unneeded Stateful Session Beans
Using Local and Remote Interfaces
Using Pass-By-Reference Semantics
Improving Performance of EJB Transactions
Use Container-Managed Transactions
Do Not Encompass User Input Time
Identify Non-Transactional Methods
Use TX_REQUIRED for Long Transaction Chains
Use Lowest Cost Database Locking
Use XA-Capable Data Sources Only When Needed
Configure JDBC Resources as One-Phase Commit Resources
Use the Least Expensive Transaction Attribute
Tuning Tips for Specific Types of EJB Components
Pre-Fetching Container Managed Relationship (CMR) Beans
Encapsulate Business Logic in Entity EJB Components
Minimize the Database Transaction Isolation Level
Tune the Message-Driven Bean's Pool Size
3. Tuning the GlassFish Server
4. Tuning the Java Runtime System
Many applications running on the GlassFish Server use servlets or JavaServer Pages (JSP) technology in the presentation tier. This section describes how to improve performance of such applications, both through coding practices and through deployment and configuration settings.
This section provides some tips on coding practices that improve servlet and JSP application performance.
The following topics are addressed here:
Follow these general guidelines to increase performance of the presentation tier:
Minimize Java synchronization in servlets.
Do not use the single thread model for servlets.
Use the servlet’s init() method to perform expensive one-time initialization.
Avoid using System.out.println() calls.
In the servlet multithread model (the default), a single instance of a servlet is created for each application server instance. All requests for a servlet on that application instance share the same servlet instance. This can lead to thread contention if there are synchronization blocks in the servlet code. Therefore, avoid using shared modified class variables because they create the need for synchronization.
Follow these guidelines when using HTTP sessions:
Create sessions sparingly. Session creation is not free. If a session is not required, do not create one.
Use javax.servlet.http.HttpSession.invalidate() to release sessions when they are no longer needed.
Keep session size small, to reduce response times. If possible, keep session size below 7 kilobytes.
Use the directive <%page session="false"%> in JSP files to prevent the GlassFish Server from automatically creating sessions when they are not necessary.
Avoid large object graphs in an HttpSession. They force serialization and add computational overhead. Generally, do not store large objects as HttpSession variables.
Do not cache transaction data in an HttpSession. Access to data in an HttpSession is not transactional. Do not use it as a cache of transactional data, which is better kept in the database and accessed using entity beans. Transactions will rollback upon failures to their original state. However, stale and inaccurate data may remain in HttpSession objects. GlassFish Server provides “read-only” bean-managed persistence entity beans for cached access to read-only data.
Follow these configuration tips to improve performance. These tips are intended for production environments, not development environments.
To improve class loading time, avoid having excessive directories in the server CLASSPATH. Put application-related classes into JAR files.
HTTP response times are dependent on how the keep-alive subsystem and the HTTP server is tuned in general. For more information, see HTTP Service Settings.
Cache servlet results when possible. For more information, see Chapter 7, Developing Web Applications, in Oracle GlassFish Server 3.1 Application Development Guide.
If an application does not contain any EJB components, deploy the application as a WAR file, not an EAR file.
Optimize SSL by using routines in the appropriate operating system library for concurrent access to heap space. The library to use depends on the version of the Solaris Operating System (SolarisOS) that you are using. To ensure that you use the correct library, set the LD_PRELOAD environment variable to specify the correct library file. For more information, refer to the following table.
|
To set the LD_PRELOAD environment variable, edit the entry for this environment variable in the startserv script. The startserv script is located is located in the bin/startserv directory of your domain.
The exact syntax to define an environment variable depends on the shell that you are using.
The security manager is expensive because calls to required resources must call the doPrivileged() method and must also check the resource with the server.policy file. If you are sure that no malicious code will be run on the server and you do not use authentication within your application, then you can disable the security manager.
See Enabling and Disabling the Security Manager in Oracle GlassFish Server 3.1 Application Development Guide for instructions on enabling or disabling the security manager. If using the GlassFish Server Administration Console, navigate to the Configurations->configuration-name->Security node and check or uncheck the Security Manager option as desired. Refer to the Administration Console online help for more information.