This section contains information to help you improve the performance of your Java Web Applications. This section includes the following topics:
In addition, see the following sections for other tuning information related to the Java Web Applications:
Compiling JSPs is a resource-intensive and relatively time-consuming process. By default, the Web Server periodically checks to see if your JSPs have been modified and dynamically reloads them. This allows you to deploy modifications without restarting the server. The reload-interval property of the jsp-config element in sun-web.xml controls how often the server checks JSPs for modifications. However, there is a small performance penalty for that checking.
When the server detects a change in a .jsp file, only that JSP is recompiled and reloaded; the entire web application is not reloaded.
If your JSPs don't change, you can improve performance by pre-compiling your JSPs.
When adding a web application, either through the Admin Console or CLI, choose the precompile JSPs option. Enabling precompiled JSPs allows all the JSPs present in the web application to be pre-compiled, and their corresponding servlet classes are grouped in the web application's WEB-INF/lib or WEB-INF/classes directory. When a JSP is accessed, it is not compiled and instead, its pre-compiled servlet is used. For more information on JSPs, see Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications. Also see Configuring Class Reloading.
If you spend a lot of time re-running the same servlet/JSP, you can cache its results and return results out of the cache the next time it is run. This is useful for common queries that all visitors to your site run: you want the results of the query to be dynamic because the results might change daily, but you don't need to run the logic for every user.
To enable caching, you configure the caching parameters in the sun-web.xml file of your application. For more details, see Caching Servlet Results in Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications.
Web Server supports the Java Security Manager. The main drawback of running the Security Manager is that it negatively impacts performance. The Java Security Manager is disabled by default when you install the product. Running the Web Server without the Security Manager might improve performance significantly for some types of applications. Based on your application and deployment needs, you should evaluate whether to run the Web Server with or without the Security Manager. For more information, see Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications.
The dynamic reload interval of the servlet container and the dynamic-reload-interval of the class-loader element in sun-web.xml control the frequency at which the server checks for changes in servlet classes. When dynamic reloading is enabled and the server detects that a .class file has changed, the entire web application is reloaded.
Set the dynamic reload interval on the configuration's Java tab ⇒ Servlet Container sub tab, or using the wadm set-servelt-container-props command. In a production environment where changes are made in a scheduled manner, set this value to 0 to prevent the server from constantly checking for updates. The default value is 0 (that is, class reloading is disabled). For more information about elements in sun-web.xml, see Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications.
For certain applications and especially if the Java Security Manager is enabled you can improve performance by ensuring that there are no unneeded directories in the classpath. To do so, change the Server Class Path, Class Path Prefix, and Class Path Suffix fields on the configuration's Java tab ⇒ General sub tab for the configuration or use the command wadm set-jvm-prop. Also, package the web application's .class files in a .jar archive in WEB-INF/lib instead of packaging the .class files as is in WEB-INF/classes, and ensure that the .war archive does not contain a WEB-INF/classes directory.
If you have relatively short sessions, try decreasing the session timeout by configuring the value of the timeOutSeconds property under the session-properties element in sun-web.xml from the default value of 10 minutes.
If you have relatively long sessions, you can try decreasing the frequency at which the session reaper runs by increasing the value of the reapIntervalSeconds property from the default value of once every minute.
For more information about these settings, and about session managers, see Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications.
In multi-process mode when the persistence-type in sun-web.xml is configured to mmap, the session manager uses cross-process locks to ensure session data integrity. These can be configured to improve performance as described below.
For Java technology-enabled servers, multi-process mode is deprecated and included for backward-compatibility only.
The implication of the number specified in the maxLocks property can be gauged by dividing the value of maxSessions with maxLocks. For example, if maxSessions = 1000 and you set maxLocks = 10, then approximately 100 sessions (1000/10) contend for the same lock. Increasing maxLocks reduces the number of sessions that contend for the same lock and might improve performance and reduce latency. However, increasing the number of locks also increases the number of open file descriptors, and reduces the number of available descriptors that would otherwise be assigned to incoming connection requests.
For more information about these settings, see Chapter 6, Session Managers, in Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications.
The following example describes the effect on process size when configuring the persistence-type="mmap" using the manager-properties properties. For more information, see MMap Session Manager (UNIX Only) in Sun Java System Web Server 7.0 Update 3 Developer’s Guide to Java Web Applications.
maxSessions = 1000 maxValuesPerSession = 10 maxValueSize = 4096
This example creates a memory mapped file of size 1000 X 10 X 4096 bytes, or ~40 MB. As this is a memory mapped file, the process size will increase by 40 MB upon startup. The larger the values you set for these parameters, the greater the increase in process size.