Learn the best practices for tuning Web applications.
Disable Page Checks
Use Custom JSP Tags
Oracle provides three specialized JSP tags that you can use in your JSP pages: cache, repeat, and process. These tags are packaged in a tag library jar file called
weblogic-tags.jar. This jar file contains classes for the tags and a tag library descriptor (TLD). To use these tags, you copy this jar file to the Web application that contains your JSPs and reference the tag library in your JSP. See Using Custom WebLogic JSP Tags (cache, process, repeat) in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
You can configure WebLogic Server to precompile your JSPs when a Web Application is
deployed or re-deployed or when WebLogic Server starts up by setting the precompile
parameter to true in the
jsp-descriptor element of the
weblogic.xml deployment descriptor. To avoid recompiling your
JSPs each time the server restarts and when you target additional servers,
precompile them using
weblogic.appc and place them in the
WEB-INF/classes folder and archive them in a
.war file. Keeping
your source files in a separate directory from the archived
file eliminates the possibility of errors caused by a JSP having a dependency on one
of the class files. For a complete explanation on how to avoid JSP recompilation,
see Avoiding Unnecessary JSP Recompilation.
Use HTML Template Compression
compress-html-template element compresses the HTML in the JSP template blocks which can improve runtime performance. If the JSP's HTML template block contains the
<pre> HTML tag, do not enable this feature.
jsp-descriptor in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
Use Service Level Agreements
You should assign servlets and JSPs to work managers based on the service level agreements required by your applications. See Thread Management.
Servlet Best Practices in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
Optimize your application so that it does as little work as possible when handling session persistence and sessions. Learn to design a session management strategy that suits your environment and application.
Managing Session Persistence
WebLogic Server offers many session persistence mechanisms that cater to the differing requirements of your application, including
Async-JDBC modes. The session persistence mechanisms are configurable at the Web application layer. Which session management strategy you choose for your application depends on real-world factors like HTTP session size, session life cycle, reliability, and session failover requirements. For example, a Web application with no failover requirements could be maintained as a single memory-based session; whereas, a Web application with session fail-over requirements could be maintained as replicated sessions or JDBC-based sessions, based on their life cycle and object size.
In terms of pure performance, replicated session persistence is a better overall choice when compared to JDBC-based persistence for session state. However, replicated-based session persistence requires the use of WebLogic clustering, so it isn't an option in a single-server environment.
On the other hand, an environment using JDBC-based persistence does not require the use of WebLogic clusters and can maintain the session state for longer periods of time in the database. One way to improve JDBC-based session persistence is to optimize your code so that it has as high a granularity for session state persistence as possible. Other factors that can improve the overall performance of JDBC-based session persistence are: the choice of database, proper database server configuration, JDBC driver, and the JDBC connection pool configuration.
For more information on managing session persistence, see:
Configuring Session Persistence in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server
HTTP Session State Replication in Administering Clusters for Oracle WebLogic Server
Using a Database for Persistent Storage (JDBC Persistence) in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server
Configuring how WebLogic Server manages sessions is a key part of tuning your application for best performance. Consider the following:
Use of sessions involves a scalability trade-off.
Use sessions sparingly. In other words, use sessions only for state that cannot realistically be kept on the client or if URL rewriting support is required. For example, keep simple bits of state, such as a user's name, directly in cookies. You can also write a wrapper class to "get" and "set" these cookies, in order to simplify the work of servlet developers working on the same project.
Keep frequently used values in local variables.
See Setting Up Session Management in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
Aggregating Session Data
This section provides best practices on how to aggregate session data. WebLogic Server tracks and replicates changes in the session by attribute so you should:
Aggregate session data that changes in tandem into a single session attribute.
Aggregate session data that changes frequently and read-only session data into separate session attributes
For example: If you use a a single large attribute that contains all the session data and only 10% of that data changes, the entire attribute has to be replicated. This causes unnecessary serialization/deserialization and network overhead. You should move the 10% of the session data that changes into a separate attribute.
Pub-Sub Tuning Guidelines
Follow the general tuning guidelines for a pub-sub server such as increasing the file descriptors, tuning the JVM options, and so on.
Increase file descriptors to cater for a large number of long-living connections, especially for applications with thousands of clients.
Tune logging level for WebLogic Server.
Tune JVM options. Suggested options:
-Xms1536m -Xmx1536m -Xns512m -XXtlaSize:min=128k,preferred=256k
Increase the maximum message. If your application publishes messages under high volumes, consider setting the value to
Enabling GZIP Compression
The WebLogic Server Web container supports HTTP content-encoding GZIP compression, which is part of HTTP/1.1. With GZIP compression, you can reduce the size of the data that a Web browser has to download, improving network bandwidth. You can tune Web applications by enabling and configuring GZIP compression at either the domain level or Web application level.
See Enabling GZIP Compression for Web Applications in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.