The following sections contain Oracle best practices for tuning Web applications and managing sessions:
You can improve performance by disabling servlet and JDP page checks. Set each of the following parameters to -1:
These are default values for production mode.
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 “ ” in Developing Web Applications, Servlets, and JSPs for 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.jspc 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
.war file eliminates the possibility of errors caused by a JSP having a dependency on one of the class files.
You should assign servlets and JSPs to work managers based on the service level agreements required by your applications. See Thread Management.
As a general rule, you should optimize your application so that it does as little work as possible when handling session persistence and sessions. The following sections provide information on how to design a session management strategy that suits your environment and application:
Weblogic Server offers five session persistence mechanisms that cater to the differing requirements of your application. 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 capability could be maintained as replicated sessions or JDBC-based sessions, based on their life cycle and object size.
In terms of pure performance, in-memory session persistence is a better overall choice when compared to JDBC-based persistence for session state. According to the authors of Session Persistence Performance in WebLogic Server 7.0: “While all session persistence mechanisms have to deal with the overhead of data serialization and deserialization, the additional overhead of the database interaction impacts the performance of the JDBC-based session persistence and causes it to under-perform compared with the in-memory replication.” However, in-memory-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 how WebLogic Server manages sessions is a key part of tuning your application for best performance. Consider the following:
For more information, see “” in Assembling and Configuring Web Applications.
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:
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.