Optimizing JSPs

This section presents some ideas for improving the responsiveness of your JSPs.

Since JSPs are compiled into servlets when they are first requested, look at the optimization techniques for servlets for additional ideas. For more information, see "Optimizing servlets".

Precompiling JSPs

Unlike servlets, which are compiled before deployment, JSP pages are compiled by JRun the first time they are requested. This can cause an apparent lag, which can appear to some users as slow responsiveness. JRun provides the option of precompiling the JSPs.

The JSPC compiler is a command-line tool that you use to compile JSPs outside the context of a web server. With the JSPC compiler, you can explicitly compile JSPs from a command line, rather than use JRun to compile them upon a request of the JSP. JSPC uses the IBM jikes compiler if it is located in the jrun_root/bin directory. Otherwise, it uses the Sun javac compiler.

When precompiling JSPs, it is also a good idea to disable JRun's autodetection of changes to those files. For more information, see "Disabling change detection".

Note:   The JSPC compiler is the same compiler that JRun uses to compile JSPs. The only difference is that you invoke the JSPC compiler from a command line.

For more information on using the JSPC compiler, see the JRun Assembly and Deployment Guide.

Disabling change detection

By default, JRun cycles through web component files (like servlets and JSPs) to detect if the files have changed since the last cycle. This process is what makes hot deployment and autodetecting changes work. However, this cycling also degrades performance and should be disabled in a production environment. It is especially unnecessary if you precompile your JSPs, as described in "Precompiling JSPs".

To disable the autodetection of changes for JSPs, set the JSPServlet's translationDisabled initialization parameter in the default-web.xml file to true, as the following example shows:

<servlet>

   <servlet-name>JSPServlet</servlet-name>
   <servlet-class>jrun.jsp.JSPServlet</servlet-class>
   <load-on-startup>1</load-on-startup>
   <init-param>
     <param-name>keepGenerated</param-name>
     <param-value>false</param-value>
   </init-param>
   <init-param>
     <param-name>translationDisabled</param-name>
     <param-value>true</param-value>
   </init-param>  
 </servlet>

Caching static data in the ServletContext object

The ServletContext object stores objects as attributes. By caching objects, such as hashtables or other structures, you reduce the processing load of your application.

The implicit application object in a JSP represents the ServletContext for that JSP. You do not have to execute a method to get the ServletContext as you do in servlets. For example, the following code sets an attribute to the ServletContext object in a JSP:

application.setAttribute("statelist", qt);

If you use the jrun:sql tag in the JRun Tag Library to get a QueryTable, you can store the QueryTable object as an application attribute. You do not have to convert the ResultSet to a Hashtable or other serializable object.

The ServletContext object behaves the same with JSPs as it does with servlets. For more information, see "Caching static data in the ServletContext object".

Disabling sessions

Every time a JSP is requested, JRun creates an HttpSession object to maintain state for each unique client. The session data is accessible in the JSP as the implicit session object. In JSPs, sessions are enabled by default.

Each session object uses up a small amount of system resources, because it is stored on the server. In addition, traffic between the client and server must include the session ID when sessions are enabled. This adds a small amount of overhead.

Use the page directive to disable sessions. Set the session attribute of the page directive to false, as shown in the following example:

<%@ page session="false" %>

Increasing response object's buffer

Increase the size of the response object's buffer to reduce socket creation.

The default size of the JSP response buffer is 8kb. JRun flushes the buffer whenever the response size reaches at least this size. Set the buffer to a larger value to reduce the number of flushes necessary, as shown in the following example:

<%@ page buffer="16kb" %>

The page directive applies to an entire JSP page and any of its included files.

To check the size of the buffer, use the getBufferSize method of the implicit response object, as shown in the following example:

Buffer size is <%= response.getBufferSize() %>

Using includes correctly

Whenever possible, use the include directive rather than the include action when including static pages. The include directive inserts the contents of the included file at compile time (in the case of JSPs, the first time the page is requested), whereas the include action fetches the included file during runtime (every time the page is requested). The latter requires more processing on the server side.

For example, if you have a static file, header.html, include the file using the include directive, as shown in the following example:

<%@ include file="/static-pages/header.html" %>

Do not include the static file with an include action, as shown in the following example:

<jsp:include page="/static-pages/header.html" flush="true" />

While Server-Side Includes (SSI) and includes perform the same tasks, do not use SSI taglets in your JSPs. JRun no longer supports SSIs.

Not flushing output

In previous versions of JRun (and any servlet engine that adhered to the earlier specifications), you were required to flush the buffer output after an include action. The required flush attribute of the include action had to be set to true. In JRun 4, the attribute defaults to false and is optional. By setting the attribute to false, you can delay the flushing of the output buffer. Depending on your page size, this can improve the performance of your JSPs.

The following code line shows setting the flush attribute to false in an include action:

<jsp:include page="myadditionalpage.jsp" flush="false" /> 

Using the setProperty shortcut

JavaBeans store state information or other data used by JSPs. Processing form variables and storing each of the input fields as a bean property can be tedious, difficult to update, and prone to errors.

The following is a typical setProperty tag that sets the form field to a JavaBean property:

<jsp:setProperty name="myBean" property="first_name" value="<%= request.getParameter("first_name") %>" />

JSPs provide a shortcut that lets you set all the bean properties with one tag.

Set property attribute to * so that the jsp:setProperty tag iterates over all the request parameters and matches parameter names and value type to bean property names and types. Each matched property is set to the value of the matching parameter. You do not specify the value parameter in the setProperty tag.

The following is an example of using the property wildcard:

<jsp:setProperty name="myBean" property="*" />

If you set the parameter value to an empty string (""), the corresponding property is not modified. If the request parameter does not have a corresponding bean property, it is ignored.

Caching static data in jspInit

JRun calls the jspInit method once when a client first requests the JSP. It is only called again if the JSP source code changes or if you restart the JRun server. The jspInit method is the equivalent of a servlet's init method.

You can override the jspInit method of a JSP and store static data in it. A common example is constructing and initializing a database connection pool. Other tasks can also be handled in the jspInit method, such as retrieving application-scoped initialization parameters.

The following code sample shows a JSP page that gets an initialization parameter in the jspInit method and later uses it in the body:

<%!

 String email;
 public void jspInit() {
  System.out.println("in jspInit()");
  javax.servlet.ServletConfig servletConfig = getServletConfig();
  email = servletConfig.getServletContext().getInitParameter("email");
}
%>
<HTML><BODY>
Email addy is: <%= email %>
</BODY></HTML>

You define the initialization parameter in the context-param block of the web.xml file, as shown in the following example:

<web-app>

...
<context-param>
 <param-name>email</param-name>
 <param-value>webmaster@macromedia.com</param-value>
</context-param>
...
</web-app>

Using application-scoped beans for caching

Setting the scope of a bean to application indicates to JRun that there should only be one instance of the bean for the current application.

For example, if you select a list of states and their abbreviations from a database and store the results as properties in an application-scoped bean, you are not required to query the database every time you want to look up the full state name.

As a result, JRun only executes one database query until you restart the server. Any JSP that has access to the bean can now get at the properties of the bean, as shown in the following example:

<jsp:usebean id="statelist" class="jrunsamples.optimize.StateList" scope="application" />

<jsp:setProperty name="statelist" property="*" />

To access a state that is one of the bean's properties, use the following line:

<jsp:getProperty name="statelist" property="MA" />

You can also change the scope of a bean to session, page, or request. If you set a bean's scope to session, you must not override sessions=true in the page directive.