Introduction

Part 1 of this article series on JavaServer Pages (JSP) in WebSphere® Application Server Technology for Developers (TD) V6 described the internal operations, configuration parameters, and process of the batch compiler, showing how batch compilation of JSPs in a predeployed application simplifies the deployment process and improves run time performance. Part 2 focuses on performance. In this article, we will take a close look at the performance tuning options available for the JSP engine in IBM WebSphere Application Server V6 TD which can be used to configure both production and development environments for optimal performance.

JSP engine configuration parameters

Many configuration parameters are available for the JSP engine in WebSphere Application Server 6.0 TD. Table 1 lists them all. In this article, we will concentrate on the parameters that relate to performance. These parameters (which appear bold in Table 1) are:

• reloadEnabled
• reloadInterval
• disableJspRuntimeCompilation
• trackDependencies
• useThreadTagPool
• usePageTagPool
• keepgenerated
• useJikes.

* Enabling custom tag handler reuse might reveal problems in tag handler code with regard to the tag's ability to be reused. A custom tag handler should always do two things:

1. The release() method of the tag handler should reset its state and release any private resources that it might have used. The JSP engine guarantees the release() method will be called before the tag handler is garbage collected.
2. In the doEndTag() method, all instance states associated with this instance must be reset.

How to configure the JSP engine parameters

WebSphere Application Server does not support the modification of deployment descriptor extension parameters through either the administrative console or admin scripting. However, this is something you will want to be able to do, so in this section we will describe a way for you to add, change and delete JSP engine configuration parameters.

JSP engine configuration parameters are stored in a Web module's configuration directory, in the WEB-INF/ibm-web-ext.xmi file. An example of a configuration directory is:

{WAS_ROOT}/config/cells/cellname/applications/enterpriseappname/deployments/ deployedname/webmodulename

If an application was deployed into WebSphere Application Server with the Use Binary Configuration flag set to true, then the WEB-INF/ibm-web-ext.xmi file will be in a Web module's binaries directory instead of the configuration directory. An example of a binaries directory is:

{WAS_ROOT}/installedApps/nodename/EnterpriseAppName/WebModuleName/

The entry for a JSP engine configuration parameter in WEB-INF/ibm-web-ext.xmi would look like this:

<jspAttributes xmi:id="JSPAttribute_6"name "keepgenerated" value="true"/>

Listing 1 shows a sample ibm-web-ext.xmi file. The bold lines represent JSP engine configuration parameters.

Listing 1. Sample ibm-web-ext.xmi file

<?xml version="1.0" encoding="UTF-8"?>
<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi=http://www.omg.org/XMI
    xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi" 
    xmi:id="WebAppExtension_1" reloadInterval="9" reloadingEnabled="true" 
    defaultErrorPage="error.jsp" additionalClassPath="" fileServingEnabled="true"
    directoryBrowsingEnabled="false" serveServletsByClassnameEnabled="true" 
    autoRequestEncoding="true" autoResponseEncoding="false">
    <webApp href="WEB-INF/web.xml#WebApp_1"/> 
    <jspAttributes xmi:id="JSPAttribute_1" name="useThreadTagPool" value="true"/>
    <jspAttributes xmi:id="JSPAttribute_2" name="verbose" value="false"/>
    <jspAttributes xmi:id="JSPAttribute_3" name="deprecation" value="false"/>
    <jspAttributes xmi:id="JSPAttribute_4" name="reloadEnabled" value="true"/>
    <jspAttributes xmi:id="JSPAttribute_5" name="reloadInterval" value="5"/>
    <jspAttributes xmi:id="JSPAttribute_6" name="keepgenerated" value="true"/>
    <!-- <jspAttributes xmi:id="JSPAttribute_7" name="trackDependencies" 
		value="true"/> -->
</webappext:WebAppExtension>

To add a JSP engine configuration parameter:

1. Open the file for editing.
2. Add a parameter line, then set the parameter and the desired value, following the example in Listing 1. Note that the integer n in JSPattribute_n has to be unique within the file.
3. Save the file and restart the server so the parameter will take effect.

To remove a configuration parameter:

1. Open the file for editing.
2. Either delete the desired line entirely, or comment it out by surrounding the line with standard comment tags, as shown in the trackDependencies attribute line in Listing 1.
3. Save the file and restart the server.

In Listing 1, WebAppExtension_1 contains reloadInterval="9" reloadingEnabled="true". In WebSphere Application Server V5, these attributes control both servlet and JSP reloading. However, in WebSphere Application Server V6 TD, they do not control JSP reloading.

Configuring the reloading of JSPs

Correctly configuring the reloading of JSPs for a particular environment is critical to JSP engine performance, regardless of whether it be for production or development. Table 2 shows the recommended settings for the associated parameters.

JSP reloading

JSP reloading is activated via the reloadEnabled parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="reloadEnabled" value="true"/>

The reloadEnabled attribute determines whether or not a JSP file will be translated and compiled at run time if the JSP file or its dependencies are modified (if trackDependencies is true). If reloadEnabled is false, a JSP is still compiled on the first request to it, if necessary, unless the parameter disableJspRuntimeCompilation is true. For example, if a classfile is older than its JSP source file, the JSP is compiled on the first request even if reloadEnabled is false. It will not be compiled on subsequent requests -- even if the JSP source file is modified or the class file is deleted -- unless reloadEnabled is true.

Reload interval

The reload interval is set via the reloadInterval parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="reloadInterval" value="5"/>

If reloading is enabled, reloadInterval determines how many seconds between requests for a JSP the engine will wait before checking to see if reloading of the JSP is necessary. Once the reloadInterval is exceeded, reload checking will be performed and the reload interval timer will be reset to 0.

Let us use an example where the reloadInterval is set to 10. This reload interval is applied to each JSP individually, which means the reloading of modified JSPs will not all occur at the same time. After a given JSP is requested, 10 seconds will pass before the JSP engine will check during the next request to that JSP to see if that JSP has been modified and needs reloading. Once this check is made (whether or not the JSP actually needs reloading) another 10 seconds will pass before the next check is made for that JSP. Since JSPs are requested at different times, the 10 second intervals will be staggered. Here is a simplified example:

• At 10:00 jsp1.jsp is requested and executed for the first time.
• Between 10:00 and 10:00:10, jsp1.jsp is requested 3 times. The engine will not do reload checking on any of these requests.
• jsp1.jsp is next requested at 10:00:15. The 10 second reloadInterval has been exceeded by 5 seconds and the JSP engine checks to see if jsp1.jsp needs reloading and reloads it if necessary. The reloadInterval timer starts counting at 10:00:15 forjsp1.jsp.

• At 10:02 jsp55.jsp is requested and executed for the first time.
• Between 10:02 and 10:02:12, jsp55.jsp is requested 2 times. The engine will not do reload checking on any of these requests.
• jsp55.jsp is next requested At 10:00:37. The 10 second reloadInterval has been exceeded by 25 seconds and the JSP engine checks to see if jsp55.jsp needs reloading and reloads it if necessary. The reloadInterval timer starts counting at 10:00:37 for jsp55.jsp.

A reload interval of 0 and reloadEnabled=true would effectively cause the JSP engine to check for reloading on every request to a JSP.

Dependency tracking

Dependency tracking is set via the trackDependencies parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="trackDependencies" value="true"/>

If reloading is enabled, trackDependencies determines whether or not the JSP engine will track modifications to the requested JSP's dependencies, as well as to the JSP itself. Three types of dependencies are tracked by the JSP engine:

• files statically included in the JSP.
• tag files that are referenced in the JSP (excluding tag files that are in JARs).
• TLDs that are referenced in the JSP (excluding TLDs that are in JARs).

An example of dependency tracking:

• toplevel.jsp statically includes footer.jspf.
• trackDependencies is true when toplevel.jsp is compiled.
• The path to footer.jspf and the timestamp of footer.jspf are stored in the class file that is generated for toplevel.jsp .
• footer.jspf is subsequently modified.
• toplevel.jsp is requested and its reload interval has been exceeded.
• The JSP engine compares the timestamp stored in the class file with footer.jspf's timestamp on disk. Since the timestamps are different, toplevel.jsp is compiled, picking up the modification to footer.jspf.
• trackDependencies must be true at the time a JSP is compiled in order for dependency tracking to work. If a JSP is compiled when trackDependencies is false, then its class file will not contain any dependency information. Also, because a dependency's timestamp is stored in a JSP class file, dependency tracking will still work even if a modification is made to a dependency when the server is not running.

Disabling compilation

Disablement of run time compilation of JSPs is set via the disableJspRuntimeCompilation parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="disableJspRuntimeCompilation" value="true"/>

If disableJspRuntimeCompilation is set to true, the JSP engine will not translate and compile JSP files at run time; the JSP engine will load only precompiled classfiles. JSP source files do not need to be present in order for the classfiles to be loaded. With this option set to true, an application can be installed without JSP source, but it must have precompiled classfiles. A Web container custom property of the same name can be used to determine the behavior of all Web modules installed in a server. If both the Web container custom property and the JSP engine option are set, then the JSP engine option takes precedence. Setting disableJspRuntimeCompilation to true automatically sets reloadEnabled to false.

The processing sequence pertaining to the reloading of JSPs when trackDependencies is false is shown in Figure 1. Figure 2 shows the additional processing that is performed when trackDependencies is true. You will see that the path taken when disableJspRuntimeCompilation is true is clearly the most efficient path.

When trackDependencies is true, the JSP engine performs additional file system access to determine if any of a JSP's dependencies have changed since the JSP was last translated and compiled. Figure 2 shows this additional processing, represented by the "No" path of the "Is JSP classfile outdated?" decision diamond.

Pooling classic tag handlers

Pooling of tag handlers is only available for classic tag handlers; pooling of simple tag handlers is not allowed by the JSP 2.0 specification. In WebSphere Application Server V6 TD, two types of classic tag handler pooling are available:

• Page level pooling: configured by the usePageTagPool parameter.
• Thread level pooling: configured by the useThreadTagPool parameter.

If both usePageTagPool and useThreadTagPool are set to true, page-based tag pooling is used.

When a custom action is used in a JSP, the JSP engine generates Java code to instantiate or reuse the class that implements the custom tag (the tag handler class). The JSP engine also generates Java code to manage the lifecycle of the tag handler. The sample code in Listing 2 shows a JSP page that uses six custom actions; this example will be referred to throughout this section.

Listing 2. Sample JSP source with custom actions

<%@ taglib uri="utility.tld" prefix="myTags" %>
<BR>
<myTags:repeat iterations="5">
	this is  tag #1!
</myTags:repeat>
<BR>
<myTags:repeat iterations="6" varName="xyz">
	this is  tag #2!
</myTags:repeat>
<BR>
<myTags:repeat iterations="2">
	this is  tag #3!
</myTags:repeat>
<BR>
<myTags:repeat iterations="9" varName="xyz">
	this is  tag #4!
</myTags:repeat>
<BR>
<myTags:repeat iterations="8" begin="7" >
	this is  tag #5!
</myTags:repeat>
<BR>
<myTags:repeat iterations="9" begin="6" >
	this is  tag #6!
</myTags:repeat>

Restrictions on tag handler reuse

Uniqueness

In order for a tag handler to be reused across custom actions, the custom actions must:

• use the same tag handler class.
• have the same set of optional attributes.

In the above sample JSP, the custom actions all use the same tag handler class, com.yourco.tags.RepeatTag, which implements the repeat custom action. However, the custom actions use different sets of attributes. The TLD (not shown), in which the repeat tag is defined, indicates that the iterations attribute is required, but the varName and begin attributes are optional. This means that in the sample JSP:

• Tags 1 and 3 can reuse a single tag handler.
• Tags 2 and 4 can reuse a single tag handler.
• Tags 5 and 6 can reuse a single tag handler.
• The tag handler reuse cannot be done across those sets of tags.

Enabling custom tag handler reuse might reveal problems in tag handler code with regard to the tag's ability to be reused. To avoid such problems, the custom tag handler developer should be sure to always make these provisions:

• The release() method of the tag handler should reset its state and release any private resources that it might have used. The JSP engine guarantees the release() method will be called before the tag handler is garbage collected.
• In the doEndTag() method, all instance states associated with this instance must be reset.

keepgenerated

Retention of generated Java source is configured with the keepgenerated parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="keepgenerated" value="true"/>

The JSP engine will retain the Java source files it generates if the keepgenerated configuration parameter is set to true. (The code samples that follow were taken from Java source generated by the JSP engine, and retained because keepgenerated was set to true.)

When tag handler pooling is not used

When tag handler pooling is not used, a tag handler object must be instantiated on every invocation of a tag. Listing 3 shows the Java code generated for tags 1 and 3 in the sample JSP. The tag handler objects _jspx_th_myTags_repeat_0 and _jspx_th_myTags_repeat_2 are instantiated using new in both cases. The sample JSP page's six tags will each have separate tag handler objects, and they will be destroyed and garbage collected when the page execution finishes. Figure 3 illustrates tag handler creation when no tag pooling is used.

Listing 3. Generated tag handler code, without tag pooling

// code generated for tag #1
com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_0 = new 
    com.yourco.tags.RepeatTag();
_jspx_th_myTags_repeat_0.setPageContext(pageContext);
_jspx_th_myTags_repeat_0.setParent(null);
_jspx_th_myTags_repeat_0.setIterations(5);
int _jspx_eval_myTags_repeat_0 = _jspx_th_myTags_repeat_0.doStartTag();

    BODY OF ACTION NOT SHOWN

// release() is called on the tag handler because its lifecycle is done
if (_jspx_th_myTags_repeat_0.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE) {
    _jspx_th_myTags_repeat_0.release();
    return;
}
_jspx_th_myTags_repeat_0.release();
.. .. .. .. .. .. .. .. 
// code generated for tag #3
com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_2 = new  
    com.yourco.tags.RepeatTag();
_jspx_th_myTags_repeat_2.setPageContext(pageContext);
_jspx_th_myTags_repeat_2.setParent(null);
_jspx_th_myTags_repeat_2.setIterations(2);
int _jspx_eval_myTags_repeat_2 = _jspx_th_myTags_repeat_2.doStartTag();

    BODY OF ACTION NOT SHOWN

// release() is called on the tag handler because its lifecycle is done
if (_jspx_th_myTags_repeat_2.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE) {
    _jspx_th_myTags_repeat_2.release();
    return;
}
_jspx_th_myTags_repeat_2.release();

When Page-Level Pooling is Used

Page-level pooling is activated via the usePageTagPool parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="usePageTagPool" value="true"/>

When page-level tag handler pooling is used, tag handlers may be reused among separate occurrences of a tag within a page, as described above under Restrictions on tag handler reuse. Listing 4 shows the Java code generated for tags 2 and 4 when usePageTagPool is true. Similar code would be generated for the two other tag handlers (for tags 1 and 3, and for 5 and 6). The result is that only three tag handler objects are created and destroyed during the execution of the JSP, instead of the six created and destroyed when tag pooling is not used. Figure 4 illustrates tag handler creation when page-level tag pooling is used.

In the _jspService method (Listing 4), an instance of each tag handler is created at the top, and each tag handler is then used when needed. The release() method is called on the handlers in the finally block at the bottom of the _jspService method, since their lifecycles are only complete at that point. The objects are garbage collected after the page finishes executing. A single tag handler is used multiple times and will be created and destroyed only once during a single request to the JSP page.

Listing 4. Sample tag handler code with page-level pooling

  public void _jspService(HttpServletRequest request, HttpServletResponse  response)
	  throws java.io.IOException, ServletException {
... ... ... ... ... ... ... ...
// An instance of each tag handler is created
// this handler is used for tags 1 and 3
	com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_0 = new 
            com.yourco.tags.RepeatTag();
// this handler is used for tags 2 and 4
	com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_1 = new 
            com.yourco.tags.RepeatTag();
// this handler is used for tags 5 and 6
	com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_2 = new 
            com.yourco.tags.RepeatTag();
... ... ... ... ... ... ... ...
  // Tag handler for tag #2; the handler was created above
	  _jspx_th_myTags_repeat_1.setPageContext(pageContext);
	  _jspx_th_myTags_repeat_1.setParent(null);
	  _jspx_th_myTags_repeat_1.setIterations(6);
	  _jspx_th_myTags_repeat_1.setVarName("xyz");
	  _jspx_eval_myTags_repeat_1 = _jspx_th_myTags_repeat_1.doStartTag();

    BODY OF ACTION NOT SHOWN

	  if (_jspx_th_myTags_repeat_1.doEndTag() == 
             javax.servlet.jsp.tagext.Tag.SKIP_PAGE){
		return;
	  }
... ... ... ... ... ... ... ...
  // Tag handler for tag #4; the same handler used for tag #2 is reused here
	  _jspx_th_myTags_repeat_1.setPageContext(pageContext);
	  _jspx_th_myTags_repeat_1.setParent(null);
	  _jspx_th_myTags_repeat_1.setIterations(9);
	  _jspx_th_myTags_repeat_1.setVarName("xyz");
	  _jspx_eval_myTags_repeat_1 = _jspx_th_myTags_repeat_1.doStartTag();
	
    BODY OF ACTION NOT SHOWN
	  if (_jspx_th_myTags_repeat_1.doEndTag() == 
             javax.servlet.jsp.tagext.Tag.SKIP_PAGE){
		return;
	  }
... ... ... ... ... ... ... ...
  // Lifecycle of the tag handlers has ended, so release is called()
	} finally {
	  if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext);
	  if (_jspx_th_myTags_repeat_0 != null) _jspx_th_myTags_repeat_0.release();
	  if (_jspx_th_myTags_repeat_1 != null) _jspx_th_myTags_repeat_1.release();
	  if (_jspx_th_myTags_repeat_2 != null) _jspx_th_myTags_repeat_2.release();
	}
}// end of _jspService method

When Thread-Level Pooling is Used

Thread-level pooling is activated via the useThreadTagPool parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="useThreadTagPool" value="true"/>

When thread-level tag handler pooling is used, tag handlers may be reused among separate occurrences of a custom action across all JSP pages in a single Web module across separate requests. Listing 5 shows the relevant Java code generated when useThreadTagPool is true. The only difference between the code generated for thread-level reuse and page-level reuse is in the initialization of the tag handlers at the top of the _jspService method and the code generated in the finally block at the bottom. Figure 5 illustrates tag handler creation when thread-level tag pooling is used.

The thread pool caches unique occurrences of tag handlers, with uniqueness as described above under Restrictions on tag handler reuse. For each unique tag found in all JSPs in a Web module, a tag handler is cached on the thread in which the JSP page was executing at the time the tag handler was encountered.

Threads are allocated by the Web container among all Web modules and a given thread may be reused across Web modules. The JSP engine's tag handler pooling mechanism guarantees that a tag cached in a given Web module will only be made available to JSP pages within that Web module, therefore avoiding ClassCastExceptions (since the tag handler object will be loaded by a classloader specific to a Web module).

(The pooling mechanism within getTagHanler() has been implemented with a single synchronization block whose code is only executed the first time a new thread is encountered, thereby minimizing the negative performance effects of synchronization.)

Listing 5. Creation of tag handler objects with thread-level pooling

  public void _jspService(HttpServletRequest request, HttpServletResponse  response)
	  throws java.io.IOException, ServletException {

... ... ... ... ... ... ... ...
// An instance of each tag handler is retrieved using the method getTagHandler()
// this handler is used for tags 1 and 3
	String _tagKey_myTags_repeat_0 = "com.yourco.tags.RepeatTag";
	com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_0 = 
	(com.yourco.tags.RepeatTag)getTagHandler(request, _tagKey_myTags_repeat_0, 
	"com.yourco.tags.RepeatTag");
// this handler is used for tags 2 and 4
	String _tagKey_myTags_repeat_1 = "com.yourco.tags.RepeatTag_varName";
	com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_1 = 
	(com.yourco.tags.RepeatTag)getTagHandler(request, _tagKey_myTags_repeat_1, 
	"com.yourco.tags.RepeatTag");
// this handler is used for tags 5 and 6
	String _tagKey_myTags_repeat_2 = "com.yourco.tags.RepeatTag_begin";
	com.yourco.tags.RepeatTag _jspx_th_myTags_repeat_2 = 
	(com.yourco.tags.RepeatTag)getTagHandler(request, _tagKey_myTags_repeat_2, 
	"com.yourco.tags.RepeatTag");
... ... ... ... ... ... ... ...
  // Tag handlers are returned to the pool; release() is called only when the the 
         //  web module is stopped and the tag handler pools for that web module are 
         //  cleared out.
	} finally {
	  if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext);
	  putTagHandler(request, _tagKey_myTags_repeat_0, _jspx_th_myTags_repeat_0);
	  putTagHandler(request, _tagKey_myTags_repeat_1, _jspx_th_myTags_repeat_1);
	  putTagHandler(request, _tagKey_myTags_repeat_2, _jspx_th_myTags_repeat_2);
	}
  }
}

Configuring the JSP engine to use Jikes

The Jikes Java compiler is activated via the useJikes parameter:

<jspAttributes xmi:id="JSPAttribute_1" name="useJikes" value="true"/>

When useJikes is true, the JSP engine will use the Jikes Java compiler instead of the default javac compiler from the JDK. Jikes is an open source compiler available here. Jikes is not shipped with WebSphere Application Server Technology for Developers V6.0, and is supported through IBM developerWorks. Jikes versions 1.8 and 1.9 have been tested with the JSP engine in WebSphere Application Server Technology for Developers V6.0 and work well.

In the JSP translation and compilation process, Jikes can result in better performance in the compilation step than the JDK's compiler.

Conclusion

The JSP engine in WebSphere Application Server V6 TD can be configured in three important ways, to best suit both production and development environments:

• Reloading of classfiles when JSPs are modified.
• Pooling of classic custom tag handler objects.
• The use of the open source Jikes java compiler.

Part 3 will conclude this article series, when we examine the architecture of the JSP engine in WebSphere Application Server Technology for Developers V6.

Acknowledgements

The author wishes to thank Todd Kaplinger and Richard Backhouse for their contributions to this article.

Resources

• WebSphere Application Server Technology for Developers V6
  
  
• Jikes open source project
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• JSP engine configuration parameters
• Configuring the reloading of JSPs
• Pooling classic tag handlers
• Restrictions on tag handler reuse
• Configuring the JSP engine to use Jikes
• Conclusion
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into WebSphere on developerWorks

Discover knowledge paths

Skill-building guides for WebSphere, Linux, open source, cloud, Java, business analytics, and more.

Special offers